[Geoserver-devel] Fixed number of threads used by ImageMosaicReader from the ImageMosaic plugin

GeoServer GeoServer Developer
1

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
  

2

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.lavoie@anonymised.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&lt;Runnable&gt;\(\)\);

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

3

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: simboss1@anonymised.com [simboss1@anonymised.com] On Behalf Of Simone Giannecchini [simone.giannecchini@anonymised.com]
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.lavoie@anonymised.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

4

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.lavoie@anonymised.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: simboss1@anonymised.com [simboss1@anonymised.com] On Behalf Of Simone Giannecchini [simone.giannecchini@anonymised.com]
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.lavoie@anonymised.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&lt;Runnable&gt;\(\)\);

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