GeoServer WFS Performance Comparison

GeoServer is one main component for Cartaro and various customer projects. Therefore we wanted to know under which conditions GeoServer delivers the best WFS (Web Feature Service) performance.

WFS enables the web access to geographical features. Per default, the Geography Markup Language (GML), a XML schema specified by the OGC is used to encode the geodata. Depending on the version of WFS, different versions of GML are being used. Additionally, GeoServer provides GeoJSON as an alternative file format with JSON notation. We wanted to know, which of these file formats gives the best performance and how big the differences are. Furthermore, we were also interested in the difference between GML 2.0 and GML 3.2. We expected a slight advance for GeoJSON due to smaller file sizes and as well an advance for GML 2.0 compared to GML 3.2.

Testing procedure

Comparison of speed was based on the parameters average number of requests per second (req/s) and average response time in milliseconds (ms).

OpenStreetMap data for Switzerland, imported into a PostgreSQL (version 9.1) / PostGIS (Version 2.0) database, were used as data source. The database was added as store to GeoServer (version 2.3.3 / Tomcat6 / OpenJDK). Two example layers with different geometry types were created and used for the test. The first layer, osm_mainroads consists mainly of lines, the second, osm_places mainly of points. PostgreSQL and GeoServer were installed on the same server (Debian Squeeze) with 4GB RAM and 8 cpu cores.

A load test with Apache JMeter was executed on a physically separated server, connected with a gigabit link. Within separate runs, 4, 8, 16 and 32 concurrent requests were performed.

Each run was executed three times to avoid random results and to detect spikes. The final result is the mean value of all three runs. Every request was performed with this parameters:

ows?service=WFS&version=2.0.0&request=GetFeature&typeName={typename}&count=200&srsName=EPSG:4326&outputFormat={formatname}

Results for osm_mainroads

Format4 Requests8 Requests16 Requests32 RequestsFile size
GML3.224,2 req/s
140 ms
40 req/s
160 ms
43 req/s
337 ms
43 req/s
700 ms
230 KB
GML283 req/s
30 ms
124 req/s
30 ms
197 req/s
45 ms
230 req/s
100 ms
150 KB
GeoJSON81,5 req/s
33 ms
110 req/s
37 ms
160 req/s
62 ms
180 req/s
142 ms
150 KB

Results for osm_places

Format4 Requests8 Requests16 Requests32 RequestsFile size
GML3.230 req/s
110 ms
51 req/s
112 ms
53 req/s
260 ms
55 req/s
510 ms
100 KB
GML2120 req/s
17 ms
140 req/s
17 ms
200 req/s
44 ms
240 req/s
75 ms
70 KB
GeoJSON117 req/s
17 ms
153 req/s
18 ms
265 req/s
25 ms
310 req/s
66 ms
40 KB

The results show clearly how much slower GML 3.2 is compared to GML 2.0 and GeoJSON. While we expected GML 2.0 to perform slightly better that GML 3.2 due to more efficient XML encodings the size of the difference is surprising. Especially average response time per request becomes unacceptably high with more than eight concurrent requests. Comparison between GML 2.0 and GeoJSON demonstrates the high impact of the data set and the file size on performance. The more complex dataset  osm_mainroads leads to same file size for GML 2.0 and GeoJSON and to a performance benefit for GML. On the other hand, the data set osm_places leads to a smaller file size and a performance benefit for GeoJSON. As result, none of both is better in every case. The difference between GML 2.0 and GeoJSON is however not that big.

If performance is important, the use of GML 3.2 is not advisable. The use of GML 2.0 and GeoJSON seems quite uncritical. If there is the choice between GML 2.0 and GeoJSON, a dedicated comparison should be done to select the faster file format.

BTW: If you would like working with us on GeoServer and other fantastic OS GIS software, please check our current job postings. We are hiring!