On Sun, Dec 20, 2009 at 4:49 PM, Andrea Aime <[email protected]> wrote: > Hi, > the last FOSS4G benchmarks showed that MapServer raster > performance improved quite a bit and it's now much > better than the GeoServer 2.0.0 one. > > Following a suggestion by Gabriel I've already suggested > on GT2 a small patch that would give GeoServer a 10% speedup. > That is good, but not enough. > > After applying the patch I noticed that GS scalability > was still lacking, and found that the threads would still > block each other while blitting the raster data over to > the final BufferedImage. > > However, if you think about it, when serving just raster > data, we don't need to copy a raster image to another > with composition, that is an un-necessary step (well, > not always, more on that later). >
Glad to see that you agree with me now :-) : http://jira.codehaus.org/browse/GEOT-2089 > So I've followed that lead and hacked a very crude > proof of concept patch that would skip the rendering > architecture fully and just encode out the result > of the raster symbolizer, appropriately rescaled. > Using it works fine as long as the coverage is not > rotated and the image requested is fully within > the coverage definition area (both conditions are > satisfied in the OSGEO benchmarks). > > I've then turn the benchmarks on the OSGEO server. > The speedup is impressive. > > For the ECW case, here are the results in responses/s: > > Threads 1 10 20 40 > GS 2.0 5.0 11.1 11.2 10.5 > MS FCGI 7.4 20.0 19.8 19.1 > GS 2.0.1+ 5.6 12.3 12.3 11.4 > GS 2.0.1csp 7.8 18.0 17.8 16.9 > > where: > GS 2.0.1+ is GS 2.0.1 with the patch I proposed on GT2 devel list > GS 2.0.1cps is 2.0.1+, with the attached patch applied. > > As you can see we're still not at the MapServer level, > but much closer. > The other benchmarks show similar results, GS becomes around > 10% slower than MapServer instead of 40-50% slower. > > I find this very encouraging. > > Now, how do we leverage this and what is missing? > > The main idea is to have a separate rendering path that > triggers when the map context contains only one layer, > with only one active rule, with a single raster symbolizer > in it. In that case we move to the "fast path". > Instead of the current hack we'd need to open a path in > the GridCoverageRenderer that would give us the final > RenderedImage for direct encoding. I am pretty sure we can relax things. I mean, as long ass we are working with coverages we can use JAI and not Java2D. > > As said above the fast path coded as it is now is incomplete. > It does not work properly when: > - a solid background is requested and the raster is translucent > (this should be doable using JAI anyways no?) > - the resulting coverage is smaller than the requested image, > we'd need to add a collar around it (again, this seems doable > with JAI too, no?) > - possibly, but I'm not sure, when the coverage needs to be > rotated > - when an image layout is used, that is, when we need to overlay > a watermark, a scalebar, and so on. > > The limitations do not seem too much of a hurdle to me, the > fast path would keep on covering well the common case of a > WMS raster background layer, which is usually drawn by itself. > > > So, what do you think? Here is what I think, let's spend 2 days together on this after Christmas and go back to where we belong, the first position! :-) What abou that? Simone. > > Cheers > Andrea > > > > -- > Andrea Aime > OpenGeo - http://opengeo.org > Expert service straight from the developers. > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
