[OpenJDK 2D-Dev] New GeoServer benchmarks with Laurent's l4 webrev

[Laurent Bourgès]

Andrea,
thanks for your time testing my patch in a real benchmark !

I think that the ratio of pisces rendering / request processing is very low
(few percents) that's why the performance gains between L1 and L4 are so
little.

How many cpu cores have your machine ?


> As you can see L1 provides most of the benefit, althought L4 managed to
> give another boost when the number of concurrent requests is higher.
> The benchmarks have been run with the thread local storage option, I did
> not manage to run them with the concurrent linked queue approach (planning
> to do that next weekend).
>

That's would be very interesting because CLQ mode is normally a bit slower
than TL mode but in a web server it will avoid wasting memory ~ 1Mb per
thread (for 200 threads ~ 200 to 300 Mb) !

I still have to finalize some array sizing (initial capacity ...) of the
renderer context to have a good compromise between performance and memory
usage.


>
> The remaining bottlenecks in the benchmarks are somewhat... funny? ;-)
> Concurrency wise the major offender is now
> FreeTypeScaler.getLaboutTableCache() (the map has several labels), CPU wise
> the CLibPNGImageWriter. write(...) is eating 75% of the overall time
> request time...
> This class comes with JAI ImageIO native extension, and it's a major
> speedup compared to the one built into the JDK, if I make GeoServer use
> that one the top performance goes down to 30req/s, a really major drop.
> Huston, we really need a faster PNG encoder! :-p
>

So you implicitly confirm that pisces only represents < 25% so let's say
10% of the request processing time.

Many you should submit a concurrency issue related to
FreeTypeScaler.getLaboutTableCache() !

Could you perform benchmark using other image format (bmp, jpg or any
faster encoding) ?
Again it would be interesting to identify the performance bottleneck in the
C library ? please look at JAI bugs ...


> I'm going to investigate a bit in that direction in the future, see if
> changing the image color model (it's BGR right now, since ductus seems to
> operate faster with that color model) does any good, and in general see if
> we can find any faster option (had a look a couple of years ago already,
> but CLib own PNG encoder was faster than everything else).
>
>
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20130617/62baa48a/attachment.html>