Container Considerations¶
Java web containers such as Tomcat or Jetty ship with configurations that allow for fast startup, but don’t always deliver the best performance.
Optimize your JVM¶
Set the following performance settings in the Java virtual machine (JVM) for your container. These settings are not specific to any container.
Option |
Description |
|
By starting with a larger heap GeoServer will not need to pause and ask the operating system for more memory during heavy load. The setting |
|
Defines an upper limit on how much heap memory Java will request from the operating system (use more if you have excess memory). By default, the JVM will use 1/4 of available system memory. The setting |
|
Increases the lifetime of “soft references” in GeoServer. GeoServer uses soft references to cache datastore, spatial reference systems, and other data structures. By increasing this value to |
|
This garbage collector pauses the application while using several threads to recover memory. Recommended if your GeoServer will be under light load and can tolerate pauses to clean up memory. |
|
Enables use of the concurrent mark sweep (CMS) garbage collector uses multiple threads to recover memory while the application is running. Recommended for GeoServer under continuous use, with heap sizes of less than 6GB. |
|
The default garbage collector since Java 9. Enables use of the Garbage First Garbage Collector (G1) using background threads to scan memory while the application is running prior to cleanup. Recommended for GeoServer under continuous load and heap sizes of 6GB or more. Additionally you may experiment with |
For more information about JVM configuration, see the article Performance tuning garbage collection in Java and The 4 Java Garbage Collectors.
Note
You can only use one garbage collector at a time. Please refrain from combining garbage collectors at runtime.
Note
If you’re serving just vector data, you’ll be streaming, so having more memory won’t increase performance. If you’re serving coverages, however, image processing will use a tile cache and benefit from more memory. As an administrator you can configure the portion of memory available as a tile cache (see the Server Config page in the Web administration interface section) - for example to use 0.75
to allocate 75%
of the heap as a tile cache.
Note
You can try out memory settings on the command line to check settings/defaults prior to use.
To check settings use java -Xms128m -Xmx756m -XX:+PrintFlagsFinal -version | grep HeapSize
:
uintx InitialHeapSize := 134217728 {product}
uintx MaxHeapSize := 792723456 {product}
Which when converted from bytes matches 128
MB initial heap size, and 756
MB max heap size.
Check defaults for your hardware using java -XX:+PrintFlagsFinal -version | grep HeapSize
:
uintx InitialHeapSize := 268435456 {product}
uintx MaxHeapSize := 4294967296 {product}
The above results (from a 16 GB laptop) amount to initial heap size of 256m, and a max heap size of around 4 GB (or around 1/4 of system memory).
Use newer Marlin rasterizer¶
To use a newer version of Marlin than that provided by your JVM, add the following to the JVM startup options:
-Xbootclasspath/a:$MARLIN_JAR
-Dsun.java2d.renderer=org.marlin.pisces.MarlinRenderingEngine
where $MARLIN_JAR
is the location of the marlin*.jar
file located in the geoserver/WEB-INF/lib directory or downloaded from the Marlin project.
The server status page shows which renderer is being used.
Enable CORS¶
The standalone distributions of GeoServer include the Jetty application server. Enable Cross-Origin Resource Sharing (CORS) to allow JavaScript applications outside of your own domain, or web browsers, to use GeoServer.
For more information on what this does and other options see the Jetty documentation or the Tomcat documentation.
Uncomment the following <filter> and <filter-mapping> from webapps/geoserver/WEB-INF/web.xml
if using Jetty:
<filter>
<filter-name>cross-origin</filter-name>
<filter-class>org.eclipse.jetty.servlets.CrossOriginFilter</filter-class>
<init-param>
<param-name>chainPreflight</param-name>
<param-value>false</param-value>
</init-param>
<init-param>
<param-name>allowedOrigins</param-name>
<param-value>*</param-value>
</init-param>
<init-param>
<param-name>allowedMethods</param-name>
<param-value>GET,POST,PUT,DELETE,HEAD,OPTIONS</param-value>
</init-param>
<init-param>
<param-name>allowedHeaders</param-name>
<param-value>*</param-value>
</init-param>
</filter>
or Tomcat:
<filter>
<filter-name>cross-origin</filter-name>
<filter-class>org.apache.catalina.filters.CorsFilter</filter-class>
<init-param>
<param-name>cors.allowed.origins</param-name>
<param-value>*</param-value>
</init-param>
<init-param>
<param-name>cors.allowed.methods</param-name>
<param-value>GET,POST,PUT,DELETE,HEAD,OPTIONS</param-value>
</init-param>
<init-param>
<param-name>cors.allowed.headers</param-name>
<param-value>*</param-value>
</init-param>
</filter>
and regardless of application server choice uncomment:
<filter-mapping>
<filter-name>cross-origin</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>