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. But what I did, (I dont know the renderer works and perhaps it is already implemented), is using multithreading when rendering multiple layers. 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. Andrea Aime writes: > Hi, > yesterday I've got confirmation there are some big bad locks > in the Java rendering subsystem that do prevent a system > to use a multicore architecture effectively: > http://jira.codehaus.org/browse/GEOS-3423 > > In fact I have been observing CPU utization well below > 100% in various mulithreaded benchmarks where the > number of client threads far exceeded the number > of available CPUs... those locks that explains it, > and I had confirmation using Yourkit. > > So today I set up to try and have the renderer do something > in the time it cannot render in parallel: try to prefetch > data from the store while rendering is happening. > > I've then run again some benchmarks, with mixed results. > StreamingRenderer + shapefile datastore gets quite a benefit > and becomes in some cases 30% faster than the shapefile > renderer itself, in some others 10% slower (but the > datastore is not optimized to work with the streaming > renderer, so I'm confident it can get faster in 100% of > the cases with some more work). > > StreamingRendere + postgis datastore is around +10/-10 > depending on the workload. > > I would have thought to always get better performance > on lighter loads, considering the second core of my > machine could have helped by doing the parallel data > fetching, but that did not always happen (it happened > big time only in one tests, where the speed at light > load almost doubled). > > Maybe there is something wrong with the way I've > coded up the prefecthin iterator? Someone more familiar > with the concurrent java utilitis might be able to tell. > > More in general, how do people feel about this? > Good for a configuration knob in the StreamingRenderer? > Or just the new default? > > 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 Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
