Service Package

GeoServer Performance Tuning

When a GeoServer map is slow, the fix is almost never more servers. It's usually one of four things: the data, the styling, the cache, or the JVM.

The hard part is knowing which one. Most deployments have no way to tell, because nobody is measuring anything.

Where the time actually goes

Imagery without internal tiling or overviews.

Ask for a country-wide view of a large GeoTIFF and GeoServer may have to read most of the file to draw a small image. Tiling the file internally and adding overviews turns that into a small read.

Vector layers drawn at every scale.

A layer with millions of features rendered at a zoom level where you can't see any of them individually. Scale-dependent styling and pre-generalized geometries fix it.

Missing database indexes.

A PostGIS table without a spatial index turns every map request into a full table scan.

No tile cache, or one that gets thrown out constantly.

GeoWebCache is built into GeoServer and a lot of deployments leave it off or never seed it.

JVM and rendering limits left at defaults that were sized for a laptop.

We measure first

Our Analytics Service captures usage and performance for every request and stores it in SQL. So you can ask it plain questions. Which layer is slow? How often has it been viewed? What zoom levels are people actually using?

That baseline goes in before we touch anything. It tells us where to spend the engagement, and it proves the fixes worked.

What the engagement delivers

  • Metrics collection installed and running, with a baseline captured up front
  • Bottleneck analysis by layer and request type
  • Fixes in order of impact: imagery tiling and overviews, vector generalization, styling, spatial indexing and PostgreSQL tuning, tile caching and seeding, JVM and container sizing
  • Before and after numbers on the layers that matter to your users
  • The metrics stay in place, so you'll see it if performance regresses

Where we've done this

On the Defense Health Agency's MedCOP, we tuned PostgreSQL behind a real-time dashboard pulling from more than 14 Military Health System sources, using GiST and BRIN indexes, partitioning, and query refactoring.

On a commercial imagery pipeline we built for SOF in INDOPACOM, imagery delivery latency dropped more than 70% compared to the legacy process.

Duration and procurement

Duration: 3 to 6 weeks.

  • Fixed scope and fixed price, agreed before work starts.
  • Available through GSA MAS (47QTCA26D002H) and Tradewinds.

Talk to an engineer about your environment.

Discuss a Requirement