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