[Geoserver-devel] Geoserver performance issues with OpenLayers

Andrea_Aime3 · February 15, 2007, 6:01pm

Hi all,
Andrea Cappugi has been running some performance comparisons
between Geoserver 1.5.x and Mapserver + Apache, specifically serving
raster files.

It seems that serving files to MapBuilder there are no significant
performance differences between the two (yahoo!).
On the other side, testing OpenLayers instead shows that Geoserver
lags quite a bit behind MapServer.
The reason is not clear, there are some hints thought.
If OpenLayers asks for tiles in parallel (something we have to check)
it may be that we're suffering from excessive synchronization.
If this is the case, running Geoserver on java 6 and using jconsole
as described here:
http://java.sun.com/developer/technicalArticles/J2SE/monitoring
(see the paragraph on lock contention).

Also, Andrea tried to run mapserver cgi under tomcat, and noticed
a significant slowdown, so another hint may be a bad out of the
box Tomcat configuration. In this case, it may be worth to try out
other containers, such as Resin, JBoss, or Glassfish.

Any suggestion or test is very much appreciated, we want Geoserver 1.5.0 to scale nicely with high client load.

Cheers
Andrea

Justin_Deoliveira · February 15, 2007, 11:32pm

Hi Andrea,

Once I get the 1.6-alpha2 release out I was planning on spending some time looking that this, and in particular doing some other geoserver "stress tests". Probably start with putting together a jmeter test suite similuating access from many clients concurrently.

That in conjunction with some of the stuff for testing synchronized access with java 6 that you sent me today should shed some light on this issue.

-Justin

Andrea Aime wrote:

Hi all,
Andrea Cappugi has been running some performance comparisons
between Geoserver 1.5.x and Mapserver + Apache, specifically serving
raster files.

It seems that serving files to MapBuilder there are no significant
performance differences between the two (yahoo!).
On the other side, testing OpenLayers instead shows that Geoserver
lags quite a bit behind MapServer.
The reason is not clear, there are some hints thought.
If OpenLayers asks for tiles in parallel (something we have to check)
it may be that we're suffering from excessive synchronization.
If this is the case, running Geoserver on java 6 and using jconsole
as described here:
http://java.sun.com/developer/technicalArticles/J2SE/monitoring
(see the paragraph on lock contention).

Also, Andrea tried to run mapserver cgi under tomcat, and noticed
a significant slowdown, so another hint may be a bad out of the
box Tomcat configuration. In this case, it may be worth to try out
other containers, such as Resin, JBoss, or Glassfish.

Any suggestion or test is very much appreciated, we want Geoserver 1.5.0 to scale nicely with high client load.

Cheers
Andrea

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1004,45d4a162284092051017194!

--
Justin Deoliveira
jdeolive@anonymised.com
The Open Planning Project
http://topp.openplans.org

Peter_Walker · February 16, 2007, 9:17am

aaime wrote:

On the other side, testing OpenLayers instead shows that Geoserver
lags quite a bit behind MapServer.

For what it's worth. I have been running OpenLayers against GeoServer1.5b2
under Tomcat/java5 and found that tiling a png was very slow and memory/cpu
intensive.
Apart from increasing memory allocation I have done no tuning.

Cheers,

Pete

--
View this message in context: http://www.nabble.com/Geoserver-performance-issues-with-OpenLayers-tf3235217.html#a9001016
Sent from the GeoServer - Dev mailing list archive at Nabble.com.

Andrea_Aime3 · February 16, 2007, 9:26am

Pete W ha scritto:

aaime wrote:

On the other side, testing OpenLayers instead shows that Geoserver
lags quite a bit behind MapServer.

For what it's worth. I have been running OpenLayers against GeoServer1.5b2
under Tomcat/java5 and found that tiling a png was very slow and memory/cpu
intensive.
Apart from increasing memory allocation I have done no tuning.

I see two potential issues here.
If the png is big, then it's the wrong format. You should try and convert it
to an uncompressed, internally tiled geotiff, using gdal_translate.
The reason is, png is structured in a way that does not allow for quick extraction
of a subset of pixel, plus we pay each time the decompression cost.

If the png is small instead, or if you've managed to serve it fast with
other software, then we're facing a geoserver performance issue, and we'll
be really interested in knowing more. For example, can you provide us the
png file, or is it something that can be freely downloaded?

Cheers
Andrea

Alessio_Fabiani · February 16, 2007, 9:35am

Guys,
I have committed few performance updates on GeoServer 1.5.x branch … if you can try them and see what happens (and if there are some issues or bugs).

Morevover, can someone please take quickly a decision on finishing the alignment of GeoTools 2.3.x with trunk in order to let me port the coverage and performance stuff on geoserver trunk too?

Cheers,
Alessio.

P.S.: There is a problem when compiling geoserver with -DconfigId=minimal … it seems that the final war doesn’t have the data directory configured correctly, while it works with other configurations.

On 2/16/07, aaime <aaime@anonymised.com> wrote:

Pete W ha scritto:

aaime wrote:

On the other side, testing OpenLayers instead shows that Geoserver
lags quite a bit behind MapServer.

For what it’s worth. I have been running OpenLayers against GeoServer1.5b2
under Tomcat/java5 and found that tiling a png was very slow and memory/cpu
intensive.
Apart from increasing memory allocation I have done no tuning.

I see two potential issues here.
If the png is big, then it’s the wrong format. You should try and convert it
to an uncompressed, internally tiled geotiff, using gdal_translate.
The reason is, png is structured in a way that does not allow for quick extraction
of a subset of pixel, plus we pay each time the decompression cost.

If the png is small instead, or if you’ve managed to serve it fast with
other software, then we’re facing a geoserver performance issue, and we’ll
be really interested in knowing more. For example, can you provide us the
png file, or is it something that can be freely downloaded?

Cheers
Andrea

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net’s Techsay panel and you’ll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

Eng. Alessio Fabiani
Vice President/CTO GeoSolutions

http://www.geo-solutions.it

Andrea_Aime3 · February 16, 2007, 1:15pm

Alessio Fabiani ha scritto:

Guys,
I have committed few performance updates on GeoServer 1.5.x branch ... if you can try them and see what happens (and if there are some issues or bugs).

Morevover, can someone please take quickly a decision on finishing the alignment of GeoTools 2.3.x with trunk in order to let me port the coverage and performance stuff on geoserver trunk too?

Alessio, we did offer our help to Simone, but he said it's a work
that he better do alone. There's nothing among the things I have done
on gt2 that still needs to be ported soo... we have to wait for Simone
afaik. During last meeting he said he would finish the forward
port late this week, no?

P.S.: There is a problem when compiling geoserver with -DconfigId=minimal ... it seems that the final war doesn't have the data directory configured correctly, while it works with other configurations.

Hum... can someone have a look at that? Today I'm off site.
Cheers
Andrea

Chris_Holmes1 · February 16, 2007, 2:32pm

Pete W wrote:

aaime wrote:

On the other side, testing OpenLayers instead shows that Geoserver
lags quite a bit behind MapServer.

For what it's worth. I have been running OpenLayers against GeoServer1.5b2
under Tomcat/java5 and found that tiling a png was very slow and memory/cpu
intensive.
Apart from increasing memory allocation I have done no tuning.

Just to confirm, this is only against rasters? Or are people getting similar performance problems against vectors on 1.5 as well?

Chris

Cheers,

Pete

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org

Simone3 · February 16, 2007, 4:18pm

Alessio was referring to taking a decision on where to put the imageio extensions.
Well, in the end, talking to him as well, I decided to remove that code from the geotools
codebase and to upload the relevant jars so.

We can probably change this in the future but I think that for the moment it draws the least resistence path.

Btw, I built again trunk on the machine where I did the work ( a windows box) hence I am ready to commit in order to test on the others machine.
Should I go?

Simone.
-------------------------------------------------------
Eng. Simone Giannecchini

President/CEO GeoSolutions
http://www.geo-solutions.it
Via Carignoni 51
550141 Camaiore (LU)
Italy
Mobile: +39 333 81 28928
-------------------------------------------------------
----- Original Message ----- From: "aaime" <aaime@anonymised.com>
To: "Alessio Fabiani" <alessio.fabiani@anonymised.com>
Cc: <geoserver-devel@lists.sourceforge.net>; "Pete W" <petwa@anonymised.com>
Sent: Friday, February 16, 2007 2:15 PM
Subject: Re: [Geoserver-devel] Geoserver performance issues with OpenLayers

Alessio Fabiani ha scritto:

Guys,
I have committed few performance updates on GeoServer 1.5.x branch ...
if you can try them and see what happens (and if there are some issues
or bugs).

Morevover, can someone please take quickly a decision on finishing the
alignment of GeoTools 2.3.x with trunk in order to let me port the
coverage and performance stuff on geoserver trunk too?

Alessio, we did offer our help to Simone, but he said it's a work
that he better do alone. There's nothing among the things I have done
on gt2 that still needs to be ported soo... we have to wait for Simone
afaik. During last meeting he said he would finish the forward
port late this week, no?

P.S.: There is a problem when compiling geoserver with
-DconfigId=minimal ... it seems that the final war doesn't have the data
directory configured correctly, while it works with other configurations.

Hum... can someone have a look at that? Today I'm off site.
Cheers
Andrea

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

jive · February 16, 2007, 4:30pm

Simone wrote:

Alessio was referring to taking a decision on where to put the imageio extensions.

Bleah - thought this was cleared up
modules/plugins -- really! (they are plugins for ImageIO )

Btw, I built again trunk on the machine where I did the work ( a windows box) hence I am ready to commit in order to test on the others machine.
Should I go?

Please
Jody

Andrea_Aime3 · February 16, 2007, 5:00pm

Simone ha scritto:

Alessio was referring to taking a decision on where to put the imageio extensions.
Well, in the end, talking to him as well, I decided to remove that code from the geotools
codebase and to upload the relevant jars so.

Bleah, not happy about it, but it's a reasonable choice anyways.

We can probably change this in the future but I think that for the moment it draws the least resistence path.

Btw, I built again trunk on the machine where I did the work ( a windows box) hence I am ready to commit in order to test on the others machine.
Should I go?

By any means, yes!
Cheers
Andrea

Simone3 · February 19, 2007, 9:31am

Ciao Pete,
could you please provide us with some more details about what you did?
As an instance, you are talking about reding PNGs, producing PNGs or both?
Could you tell us a bit about HW & SW platform, java version and GeoServer Configuration?

Cheers,
Simone.
-------------------------------------------------------
Eng. Simone Giannecchini

President/CEO GeoSolutions
http://www.geo-solutions.it
Via Carignoni 51
550141 Camaiore (LU)
Italy
Mobile: +39 333 81 28928
-------------------------------------------------------
----- Original Message ----- From: "Pete W" <petwa@anonymised.com>
To: <geoserver-devel@lists.sourceforge.net>
Sent: Friday, February 16, 2007 10:17 AM
Subject: Re: [Geoserver-devel] Geoserver performance issues with OpenLayers

aaime wrote:

On the other side, testing OpenLayers instead shows that Geoserver
lags quite a bit behind MapServer.

For what it's worth. I have been running OpenLayers against GeoServer1.5b2
under Tomcat/java5 and found that tiling a png was very slow and memory/cpu
intensive.
Apart from increasing memory allocation I have done no tuning.

Cheers,

Pete

--
View this message in context: http://www.nabble.com/Geoserver-performance-issues-with-OpenLayers-tf3235217.html#a9001016
Sent from the GeoServer - Dev mailing list archive at Nabble.com.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Peter_Walker · February 19, 2007, 11:54am

On Mon, 2007-02-19 at 10:31 +0100, Simone wrote:

Ciao Pete,
could you please provide us with some more details about what you did?
As an instance, you are talking about reding PNGs, producing PNGs or both?
Could you tell us a bit about HW & SW platform, java version and GeoServer
Configuration?

Hardware is a Dell PowerEdge 1600SC with dual 1.8Ghz CPUs and 1GB RAM
Fedora Core 5
java version "1.5.0_08"
apache-tomcat-5.5.17
GeoServer 1.5b2

The image is stored as a png and requested as a png by OpenLayers.
PNG image data, 2669 x 1779, 8-bit colormap, non-interlaced

I see similar (but not as extreme) behaviour with the usa.png supplied
as sample data. It takes about 30 sec to draw the new tiles when I pan
across the image.

Is this about what I should expect?

Let me know if you need more info.

Cheers,

Pete

--------------------------------------------------------
Plymouth Marine Laboratory
Prospect Place
Plymouth
PL1 3DH

Website: www.pml.ac.uk
Registered Charity No. 1091222
Company No. 4178503

PML is a member of the Plymouth Marine Sciences Partnership
Website: www.pmsp.org.uk

--------------------------------------------------------
This e-mail, its content and any file attachments are confidential.
If you have received this e-mail in error please do not copy, disclose
it to any third party or use the contents or attachments in any way.
Please notify the sender by replying to this e-mail or e-mail
forinfo@anonymised.com and then delete the email without making any copies
or using it in any other way.

The content of this message may contain personal views which are not
the views of Plymouth Marine Laboratory unless specifically stated.

Email transmission cannot be guaranteed to be secure or error free as
information may be intercepted, corrupted, lost, destroyed, arrive
late or incomplete or contain viruses. Plymouth Marine Laboratory
accepts no liability for any loss or damage which may be caused by
software viruses.