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

[Andrea Aime]

Hi,
today I've been playing with Laurent's L4 webrev (
http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-4/) and run some new
benchmarks.
This time I've not limited myself to run the benchmarks, but I've also
inspected with a profiler the synchronization bottlenecks (monitor
profiling).
Laurent's patch made some issues in the GeoServer code base more evident,
so I fixed them and re-run the benchmarks once more, getting improvements
also in the vanilla JDK8 case, but also making the benefits of Laurent's
patches more evident.

Here are the results of the same benchmark I run last time (for those that
did not follow, it's FOSS4G 2010 benchmark,  a WMS benchmark with real
world data over the entire Spain, run with a fixed set of requests with an
increasing number of concurrent clients making the requests. The results
are in requests/second, the last two column provide the performance
difference between the various setups as a percentage):

  *Threads* *Vanilla* *L1* *L4* *Vanilla → L1* *L1 → l4*  1 12,20 13,12
13,09 7,59% -0,27%  2 20,16 21,04 21,45 4,40% 1,93%  4 32,29 34,88 35,08
8,00% 0,56%  8 43,30 44,71 44,00 3,26% -1,58%  16 47,36 49,49 50,99 4,49%
3,05%  32 44,19 50,55 52,11 14,37% 3,09%  64 42,77 44,56 47,31 4,18% 6,17%

Vanilla is OpenJDK8 as is, L1 is
http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-1/ and L4 is
http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-4/

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).

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

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).

Cheers
Andrea

-- 
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20130616/9219e4a3/attachment.html>