On Wed, Feb 2, 2011 at 3:08 PM, Andrea Aime <[email protected]> wrote: > On Wed, Feb 2, 2011 at 11:11 AM, Andrea Aime > <[email protected]> wrote: >> The above is actually the reason why I did not try to pursue this >> design in the past, >> getting it right is relatively hard and it only helps on light loads, >> while it makes everything >> way easier to break under high load. Given GS is a server side >> application, one that >> is meant to serve multiple requests in parallel, I left the fully >> parallelized approach >> to desktop apps (where it makes a lot more sense, but still should be >> guarded to >> avoid chewing up all the machine resources on non toy maps). > > Meh, as usual I end up sounding a lot more negative than I intend to. > If we can get a speed improvements on the lighter loads I'm all for it, > we just need to address it very carefully so that all the work that has > been done in the past to ensure proper resource usage (and thus, > stability) is not undermined by the newest changes
And following up with a more practical point of view, what would it take to make such renderer without the risk of getting GS down? That renderer would need: - a way to estimate the max number of threads allowed to render in parallel without breaking the memory limits (that sets the overall thread pool size for the rendering operation) - a way to tell where each data source is coming from, so that we can make a "file system" zone, a "database x" zone, a "database y" zone and so on, and ensure no more than x threads from the same rendering request hit it at the same time (this can be done, for example, by giving each zone a bounded queue and have the threads put or get a token in the queue before starting). This might be somewhat more difficult as the map context only contains feature collections, so I guess we'd have to use custom map layer subclasses that are marked with the respective zone - also set a max number of threads that can work globally (so a global thread pool) I guess that for starters the zone limits and the global thread pool size could be set by environment variable, this would make for a self contained rendering class that could be coded and enabled with yet another system wide variable that allows the brave to try it out. If it proves not to undermine the stability and througput of GS under load we can adopt it and turn all the system variables into actual tunables exposed to the administrator Performance wise there is also the tradeoff of merging the rendering surfaces: it takes time to merge togheter two rgba images and if you just render a few vectors on them in parallel you might actually end up slowing down things.... Cheers Andrea -- Ing. Andrea Aime Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584962313 fax: +39 0584962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ----------------------------------------------------- ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
