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
