Hi,

I'm running a Jmeter test that send some WMS requests to Geoserver to 
investigate a performance issue we encounter while deploying our app. I can see 
that the time to respond is really slowing down for more than 5 users.

Looking at the threads usage using JVisualVM, I've found that the number of 
threads used by the ImageMosaicReader was not adjusted to reach the 
maximumPoolSize. 

I've done some tests by increasing the corePoolSize value to a higher value 
and, in my case, the average time to process a WMS request is faster.

An average of 2852ms with corePoolSize=8 threads compare to 3885ms with 
corePoolSixe=4 with 15 users doing 10 calls each.

We're running Geoserver 2.0.2 on a 2 Quad-Core server with 32GB RAM, so our 
server can handle more threads.

Unfortunately, the corePoolSize and maximumPoolSize value are hard coded in the 
ImageMosaicReader class and since the ThreadPoolExecutor is using a 
LinkedBlockingQueue, the maximumPoolSize is not used. In other word, the number 
of useful threads is 4:


public final class ImageMosaicReader extends AbstractGridCoverage2DReader 
implements GridCoverageReader {

        /** Logger. */
        private final static Logger LOGGER = 
org.geotools.util.logging.Logging.getLogger(ImageMosaicReader.class);

        final static ExecutorService multiThreadedLoader= new 
ThreadPoolExecutor(4,8,30,TimeUnit.SECONDS,new LinkedBlockingQueue<Runnable>());
        
Is there a particular reason to have those values hard coded?   

Is there any chance that a future version includes a way to customize those 
values either by the Geoserver UI or a properties file?

And in the mean time, is there another possible workaround other than 
recompiling the gt-imagemosaic jar.


Thank you
        


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Reply via email to