Developer’s Corner: High Performance JPEG Encoder for GeoServer
We would like to talk about some work we did lately to add support in GeoServer for encoding JPEG GetMap responses using the libjpeg-turbo library.
Citing its website the libjpeg-turbo library is a derivative of libjpeg that uses SIMD instructions (MMX, SSE2, NEON) to accelerate baseline JPEG compression and decompression on x86, x86-64, and ARM systems. On such systems, libjpeg-turbo is generally 2-4x faster than the unmodified version of libjpeg, all else being equal. I guess it is pretty clear now why we wrote this extension!
The work was done in a quite modular manner. We created an ImageIO Writer and Reader hosted by the ImageIO-Ext Open Source project and then we created a community extension for GeoServer to use the writer for encoding WMS GetMap responses. The extension should work fine on GeoServer 2.2.x, 2.3.x and 2.4.x (a.k.a master).
Documentation has been created as well, check here. Long story short, aside from the usual process for installing an extension (dropping its jars inside the GeoServer WEB-INF/lib directory) it is required to install the native counterpart for libjpeg-turbo for which there is enough instructions on the documentation linked above.
In order to provide some numbers on a typical use case we run a quick set of performance tests on a normal laptop with some sample data. Here is what we did:
- Intel i5 quad-core
- 8GB RAM
- 500 GB HD (7200 RPM)
- GeoServer Master build
- libjpeg-turbo 1.2.1
- Oracle JDK 1.6.0_27 running in server mode
I used a preprocessed geotiff from Natural Earth, here
is the gdalinfo on it. The image on disk is a bit more than 1GB. You can find the original geotiff here
We used the FOSS4G Shootout Python script to generate 700 request for the layer with randomized sizes and resolutions. We then used Apache JMeter from a different machine on the same LAN to simulate the load from 5, 10, 20 and 30 concurrent threads. You can find the original JMeter JMX files here
I am not particularly interested in the absolute values as the results have been collected after a few warm-up runs hence they are extremely good, but the speed up in throughput and (from between 40% and 80%) as well as the decrease in response times (up to 40% in some conditions) is worth to be mentioned.
I reported the original charts from the document here below for quick inspection.
Although the numbers above are not intened by any mean to represent a scientific measure of the performance gain attained using the libjpeg-turbo encoder, they provide some evidence (we have of course used this plugin in a certain nuber of use cases that showed the same behavior…) of the speed-up one would expect, at least on Intel architectures.
Last but not least, we believe it is worth to mention that this work was performed via our GeoSolutions Enterprise Service
. Therefore, if you’d like to know more about what we could achieve together, do not hesitate and get in touch with us
The GeoSolutions team,