Developer's Corner: Audit your GeoServer installation with the new monitoring extensions

When running one or more GeoServer in production it is often important to keep tabs on the server and its workload.

The monitoring community module, available among the nightly builds, allows to track requests flowing into the server and expose basic statistics about the traffic in terms of OGC services being used.

Configured in "history" mode it also stores all relevant request details into a database, allowing other tools to perform detailed usage analysis in post processing.



This is great, but has some limitations. In particular, but storing all request details into a single database table the speed at which the new request details are inserted decreases over time in most relational databases, adding overhead to GeoServer as well, especially during peak loads.



We recently developed an alternative storage that uses plain text files instead, with file rolling when the file reaches a configurable record count as well as every time midnight is reached.

All the request details are first collected and fed into a queue that is then read by a separate thread doing the actual logging: this ensures there is no significant overhead and that the logging happens without slowing down the main thread.

Separate applications, running offline periodically, can then grab the files generated and compute whatever statistics are deemed necessary without impacting on GeoSeGeoServerrver's activity.

The logging by default builds XML files with all the details of a request, including the body of posts requests, as shown in this example file. However the Freemarker templates driving the logging allow the administrator to perform a completely different kind of logging, maybe duplicating the Apache log format or generate JSON documents instead.

See the online documentation for details on how it's possible to configure the logging module.

Interested in hearing more about GeoServer performance monitoring and auditing? Let us know!

Regards,

the GeoSolutions Team.

Developer corner: Compact choropleth map styles with the Categorize function

One common task in cartography making is setting up a choropleth map, that is, a map showing different shades of colors or patters for different categories of a statistical attribute, such as population.

GeoServer example data directory ships with two such examples using an old USA states map having, among others, population count per state. The two following maps should be familar, the first is using the population style, the other the pophatch style:

The original styles use a typical SLD 1.0 setup to build choropleth maps, that is, use rule filters to tell apart the categories.
This is fine, but also quite verbose, especially since the only thing that changes between one rule and then next is a color or a graphic size.

SE 1.1 introduces the Categorize function, mainly as a way to categorize raster data, but in such a way that it can be used against vector data as well.
GeoServer and GeoTools offer the possibility to use the categorize function in SLD 1.0 as well, calling it like any other filter function.

This is the polygon symbolizer using the categorize function to select different colors based on the number of people in the state:

The function call should be read as "categorize based on the PERSONS attribute, use color red if we have less than 20M people, green between 20M and 40M, and blue above 40M".

As you can see the expression is quite more compact. Indeed the color based SLD goes down from 96 lines to 56 lines, whilst the hatch based SLD goes down from 124 lines to 69 lines.

What about performance, you might wonder? If you have few rules, say, less than 10, it should be more or less the same, whilst if you have a very large style, with hundreds of these rules, you should expect to see an improvement, the more visible the more rules you have.

In the next installment I'll show you how to have a compact style in case you want continuous changes of color based on the attribute value using the interpolate function instead.

Do you also have an interest in filter functions and their abilities? Or do you have a style that is growing beyond control and with a less than desirable performance? Let us know!

Regards,
the GeoSolutions Team.