Christian Müller ha scritto: > Hi, interesting discussion. I did something similar with my imagemosiac > jdbc module for decoding the tiles. > Scaled up well, the IBM power p6 has 4 CPUs at 100 %, consuming energy > like a washing machine. > I had also the idea using a prefetch mechanism like yours using jdbc > data stores, I omitted it. The reason is that > fetching the 2,3,.... row is not very expensive. The expensive part is > either executeQuery or, if the the execution is deferred, the first > hasNext() or next() call . There was no real performance improvement. I > think that is what you see when testing with PostGis.
I guess you're right... well, at least it the fetch is small. When grabbing a sizeable amount of data also fetching the next records should have some cost. Like, atm we get 1000 records at a time from the database, if the db is not local each network communication has to come to some expense, no? > But what I did, (I dont know the renderer works and perhaps it is > already implemented), is using multithreading when rendering multiple > layers. Nope, the renderer is not working like this for the moment. I hope to allow such option in the future (when and if we'll find time to rewrite the renderer). The downside of such an approach is that if not implemented properly it may well thrash the machine (like in uDig some years ago, trying to render 20 shapefiles in parallel it basically killed the desktop) > The drawing itself has to be serial, but starting iterating for each > layer (fetching the first geometry for each layer) also uses multiple > cores at the client machine. This works well too and is a good solution > for layers where getting the first geometry is the expensive part. Yup, seems like a nice improvement for the cases in which the server is under light load. But there has to be some resource control, in particular, no more than two threads should hit the local filesystem, no more than two should hit the same remote server, and so on. Used indiscriminately threading just ends up thrashing either the disk or the network conneciton, and also ends up requiring much more memory (n times the size of the produced image, where n is the number of concurrent threads dwraing, each one on his surface). Time is tirant... I hope we'll get enough to redo the rendering subsystem some day Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
