Logging may visibly affect the performance of your server. High logging levels are often necessary to track down issues, but by default you should run with low levels. (You can switch the logging levels while GeoServer is running.)

A service strategy is the method in which output is served to the client. This is a balance between proper form (being absolutely sure of reporting errors with the proper OGC codes, etc) and speed (serving output as quickly as possible). This is a decision to be made based on the function that GeoServer is providing. You can configure the service strategy by modifying the web.xml file of your GeoServer instance.

The possible strategies are:

Strategy

Description

SPEED

Serves output right away. This is the fastest strategy, but proper OGC errors are usually omitted.

BUFFER

Stores the whole result in memory, and then serves it after the output is complete. This ensures proper OGC error reporting, but delays the response quite a bit and can exhaust memory if the response is large.

FILE

Similar to BUFFER, but stores the whole result in a file instead of in memory. Slower than BUFFER, but ensures there won’t be memory issues.

PARTIAL-BUFFER

A balance between BUFFER and SPEED, this strategy tries to buffer in memory a few KB of response, then serves the full output.

This is isn’t a performance consideration, but is just as important. In order to make GeoServer as useful as possible, you should customize the server’s metadata to your organization. It may be tempting to skip some of the configuration steps, and leave in the same keywords and abstract as the sample, but this will only confuse potential users.

Suggestions:

Fill out the WFS, WMS, and WCS Contents sections (this info will be broadcast as part of the capabilities documents)

GeoServer includes support for WFS-T (transactions) by default, which lets users modify your data. If you don’t want your database modified, you can turn off transactions in the the Web administration interface. Set the Service Level to Basic.

If you’d like some users to be able to modify some but not all of your data, you will have to set up an external security service. An easy way to accomplish this is to run two GeoServer instances and configure them differently, and use authentication to only allow certain users to have access.

For extra security, make sure that the connection to the datastore that is open to all is through a user who has read-only permissions. This will eliminate the possibility of a SQL injection (though GeoServer is generally not vulnerable to that sort of attack).

Server-side caching of WMS tiles is the best way to increase performance. In caching, pre-rendered tiles will be saved, eliminating the need for redundant WMS calls. There are several ways to set up WMS caching for GeoServer. GeoWebCache is the simplest method, as it comes bundled with GeoServer. (See the section on GeoWebCache for more details.) Another option is TileCache. You can also use a more generic caching system, such as OSCache (an embedded cache service) or Squid (a web cache proxy).

In order to prevent clickjacking attacks GeoServer defaults to setting the X-Frame-Options HTTP
header to SAMEORIGIN. This prevents GeoServer from being embedded into an iFrame, which prevents certain
kinds of security vulnerabilities. See the OWASP Clickjacking entry for details.

If you wish to change this behavior you can do so through the following properties:

geoserver.xframe.shouldSetPolicy: controls whether the X-Frame-Options filter should be set at all. Default is true.

geoserver.xframe.policy: controls what the set the X-Frame-Options header to. Default is SAMEORIGIN valid options are DENY, SAMEORIGIN and ALLOW-FROM [uri]

These properties can be set either via Java system property, command line argument (-D), environment
variable or web.xml init parameter.