see http://jira.codehaus.org/browse/GEOT-3145 ------------------------------------------------------- Ing. Simone Giannecchini GeoSolutions S.A.S. Founder - Software Engineer Via Carignoni 51 55041 Camaiore (LU) Italy
phone: +39 0584983027 fax: +39 0584983027 mob: +39 333 8128928 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.linkedin.com/in/simonegiannecchini http://twitter.com/simogeo ------------------------------------------------------- On Wed, Jun 16, 2010 at 4:44 PM, Mathieu Lavoie <mathieu.lav...@valtus.com> wrote: > Hi Simone, > > First thank you for your quick answer. > > > I've updated our layers to use the multithreading. With the default > configuration I've found it's faster this way for less than 5 users. > > > My test was to create x users and generate 10 requests for each of them. > > I did a lot of testing using different configuration. > > I've tried changing the workQueue object ofthe ThreadPoolExecutor for > SynchronousQueue and ArrayBlockingQueue. In both cases some tasks are dropped > (pass +/-15 users). So these 2 queues might be useful but require more fine > tuning. > > I've switched back to the default queue, LinkedBlockingQueue with > corePoolSize set to 16 which gave me the vest overall result. > > Here are some results: > > > AllowMultithreading=true, default pool setting > users avg Median 90% > 1 1670 1986 2416 > 5 1495 1510 2381 > 10 2278 2289 3392 > 15 3885 3945 5136 > > AllowMultithreading=false > > users avg Median 90% > 1 2217 2417 3253 > 5 1763 1635 3037 > 10 2370 2325 3450 > 15 2821 2553 4779 > > AllowMultithreading=true, LinkedBlockingQueue with corePoolSize=16 > users avg Median 90% > 1 1669 1980 2407 > 5 1371 1279 2207 > 10 1756 1580 2798 > 15 2599 2464 4430 > > thanks > > Mathieu > > > > ________________________________________ > From: simbo...@gmail.com [simbo...@gmail.com] On Behalf Of Simone > Giannecchini [simone.giannecch...@geo-solutions.it] > Sent: Wednesday, June 16, 2010 6:28 AM > To: Mathieu Lavoie > Cc: geoserver-devel@lists.sourceforge.net > Subject: Re: [Geoserver-devel] Fixed number of threads used by > ImageMosaicReader from the ImageMosaic plugin > > Ciao Mathieu, > two things: > > -1- By default we do not use that multithreading switch, so it should > not impact your requests > -2- In newer version of the plugin we are making that thread pool configurable > > Question, which are the values for the mosaic parameters that you are using? > > Ciao, > Simone. > ------------------------------------------------------- > Ing. Simone Giannecchini > GeoSolutions S.A.S. > Founder - Software Engineer > Via Carignoni 51 > 55041 Camaiore (LU) > Italy > > phone: +39 0584983027 > fax: +39 0584983027 > mob: +39 333 8128928 > > > http://www.geo-solutions.it > http://geo-solutions.blogspot.com/ > http://www.linkedin.com/in/simonegiannecchini > http://twitter.com/simogeo > > ------------------------------------------------------- > > > > On Tue, Jun 15, 2010 at 5:39 PM, Mathieu Lavoie > <mathieu.lav...@valtus.com> wrote: >> 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 >> Geoserver-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >> > ------------------------------------------------------------------------------ > 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 > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > ------------------------------------------------------------------------------ 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 Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
