[Geoserver-users] GeoServer WMS performance bottleneck in org.geotools.image.ImageWorker?

GeoServer GeoServer User
1

Hey there

I've read some things here and there, but decided it would be best to confirm with you guys.

So, I have a simple GeoServer 2.3.0 installation on my desktop: quad-core i5 4GB RAM with Windows 7 64 bits, JDK 6u32 (32bits) with native JAI . I then open up the layer preview for topp:states, and set options to use tiling and a larger width/height (1200x800).

Ok, so now if I simply zoom in and out crazily, just by myself, I am able to occupy ~30% of the CPU (all cores included). I then did some profiling (on another version of GeoServer, 2.1.4) and it seemed like most of the CPU load refferred to methods from org.geotools.image.ImageWorker, namely writePNG or writeJPEG (dependending on the format specified). I was also able to confirm that the writePNG method does go through the code that uses native JAI acceleration (which seems to help a little, but not incredibly so)

So I wonder: is this really supposed to happen? Is encoding the image the real bottleneck for simple layers like this? Is there anything I can do to improve this performance?

Thanks
Milton

--

Milton Jonathan
Grupo GIS e Meio Ambiente
Tecgraf/PUC-Rio
Tel: +55-21-3527-2502

2

On Fri, Apr 12, 2013 at 11:00 PM, Milton Jonathan <milton@anonymised.com

wrote:

So I wonder: is this really supposed to happen? Is encoding the image
the real bottleneck for simple layers like this? Is there anything I can
do to improve this performance?

For a complex map normally the split is roughly 1/3 each divided among data
loading,
painting, and output encoding, but yes, for simple maps that do not have
much
to load or draw PNG encoding will surely be the slowest part, unfortunately
PNG is both
heavy to produce and to read, but it's the best option at the moment if
you're drawing
vector data.
For imagery go JPEG instead, which is already significantly faster, and if
you want
an extra boost, upgrade to GeoServer 2.3.0 and install the JPEG-Turbo
extension:
http://docs.geoserver.org/stable/en/user/community/libjpeg-turbo/index.html

Cheers
Andrea

--

GeoServer training in Milan, 6th & 7th June 2013! Visit
http://geoserver.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

3

OK thanks Andrea

I understand then that the JPEG-Turbo extension would also give a boost in this situation where I have a simple map with light vector data, right?

Milton

···

On 13/04/2013 03:08, Andrea Aime wrote:

On Fri, Apr 12, 2013 at 11:00 PM, Milton Jonathan <milton@anonymised.com> wrote:

So I wonder: is this really supposed to happen? Is encoding the image
the real bottleneck for simple layers like this? Is there anything I can
do to improve this performance?

For a complex map normally the split is roughly 1/3 each divided among data loading,
painting, and output encoding, but yes, for simple maps that do not have much
to load or draw PNG encoding will surely be the slowest part, unfortunately PNG is both
heavy to produce and to read, but it’s the best option at the moment if you’re drawing
vector data.
For imagery go JPEG instead, which is already significantly faster, and if you want
an extra boost, upgrade to GeoServer 2.3.0 and install the JPEG-Turbo extension:
http://docs.geoserver.org/stable/en/user/community/libjpeg-turbo/index.html

Cheers
Andrea

–

==
GeoServer training in Milan, 6th & 7th June 2013! Visit http://geoserver.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-- 

Milton Jonathan
Grupo GIS e Meio Ambiente
Tecgraf/PUC-Rio
Tel: +55-21-3527-2502
4

On Sat, Apr 13, 2013 at 12:56 PM, Milton Jonathan <milton@anonymised.com

wrote:

OK thanks Andrea

I understand then that the JPEG-Turbo extension would also give a boost in
this situation where I have a simple map with light vector data, right?

Only if you are encoding the outputs in jpeg, which is normally something
people do not do, since jpeg compression creates visible compression
artifacts in solid color areas

Cheers
Andrea

--

GeoServer training in Milan, 6th & 7th June 2013! Visit
http://geoserver.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

5

Do you think GIF output could be a faster option than PNG ?

I guess you’ll only get 8bit color but it should be ebough for simple WMS vector drawing.

Regards,

Laurent

···

OK thanks Andrea

I understand then that the JPEG-Turbo extension would also give a boost in this situation where I have a simple map with light vector data, right?

Only if you are encoding the outputs in jpeg, which is normally something people do not do, since jpeg compression creates visible compression
artifacts in solid color areas

Cheers
Andrea

–

==
GeoServer training in Milan, 6th & 7th June 2013! Visit http://geoserver.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

6

On Sat, Apr 13, 2013 at 11:48 PM, PREVOSTO, Laurent <
laurent.prevosto@anonymised.com> wrote:

Do you think GIF output could be a faster option than PNG ?

I guess you'll only get 8bit color but it should be ebough for simple
WMS vector drawing.

GIF is suitable only for background maps where you have no transparency in
the request. The reason is,
GIF only supports a single transparent value, and in order to preserve
antialiasing in transparent request,
one really needs to support partially transparent pixels as well, which
only PNG8 supports.

You can try with PNG8, the extra effort to compute the optimal 256 colors
palette on the fly is normally
compensated by faster network transfer. Of course, this is an option if you
are experiencing slowness
across the internet, if you are on the local network and the CPU is already
pegged, it will just make
things worse

Cheers
Andrea

--

GeoServer training in Milan, 6th & 7th June 2013! Visit
http://geoserver.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------