Andrea,<br>thanks for your time testing my patch in a real benchmark !<br><br>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.<br>
<br>How many cpu cores have your machine ?<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>
<br></div><div>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.</div><div>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).</div>
</div></div></blockquote><div><br>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) ! <br>
<br>I still have to finalize some array sizing (initial capacity ...) of the renderer context to have a good compromise between performance and memory usage.<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div>
<div><br></div><div>The remaining bottlenecks in the benchmarks are somewhat... funny? ;-)</div><div>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... </div>

<div>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.</div>

<div>Huston, we really need a faster PNG encoder! :-p</div></div></div></blockquote><div><br>So you implicitly confirm that pisces only represents < 25% so let's say 10% of the request processing time.<br><br>Many you should submit a concurrency issue related to FreeTypeScaler.getLaboutTableCache() !<br>
<br>Could you perform benchmark using other image format (bmp, jpg or any faster encoding) ?<br>Again it would be interesting to identify the performance bottleneck in the C library ? please look at JAI bugs ...<br> </div>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>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).</div>
<br></div></div></blockquote><div> </div><div>Laurent<br> </div></div>