I am having a tough time making this map run smoothly (play around with it for a bit, you'll see). I have taken a few tips from OSGeo's Making Maps Fast document, but I think there's another issue because:

A) sometimes the map runs just fine, but when I refresh the page it takes a very long time to load and/or times out on some layers, and

B) occasionally when zooming in/out, the Bing basemaps change appropriately but my layers stay at their original scale.

I have not yet taken the step of simplifying/generalizing geometries because, although it may help, I don't think that's the issue. I'm only bringing in a few layers on the initial load, and they're not overly complex, at least not complex enough to slow things down this much IMO. Also, I briefly employed GeoWebCache, but that didn't make much difference either.

In terms of additional performance improvement techniques, I have also followed GeoServer's container considerations and my JAVA_OPTS look like so:

grep -i useparallelgc /etc/*/*
/etc/init.d/tomcat6:export JAVA_OPTS="-server -Xmx256M -Xms48m -XX:SoftRefLRUPolicyMSPerMB=36000 -XX:MaxPermSize=128m -XX:+UseParallelGC"
/etc/java/java.conf:export JAVA_OPTS="-server -Xmx256M -Xms48m -XX:SoftRefLRUPolicyMSPerMB=36000 -XX:MaxPermSize=128m -XX:+UseParallelGC"

Here's my environment:

  • GeoServer 2.1.1
  • PostGIS 1.5.3
  • PostgreSQL 8.4ish
  • OpenLayers 2.11
  • GeoExt 1.1
  • ExtJS 3.4.0
  • Amazon EC2 Linux Micro Instance (awww, 613 MB of memory)

If it helps, here is my GeoServer server status:

Data directory      /usr/share/tomcat6/webapps/geoserver/data   
Locks           0   
Connections     2   
Memory Usage        144 MB  
JVM Version     Sun Microsystems Inc.: 1.6.0_29 (Java HotSpot(TM) 64-Bit Server VM) 
Available Fonts     GeoServer can access 97 different fonts. Full list of available fonts   
Native JAI      true    
Native JAI ImageIO  false   
JAI Maximum Memory  113 MB  
JAI Memory Usage    0 KB    
JAI Memory Threshold    75.0    
# of JAI Tile Threads   7   

JAI Tile Thread Priority        5   
ThreadPoolExecutor Core Pool Size   5   
ThreadPoolExecutor Max Pool Size    10  
ThreadPoolExecutor Keep Alive Time (ms) 30000   
Update Sequence             236

You can look at my code on the website itself, but here is an example of the parameters I'm using for all my WMS layers (tried them as tiled layers, which didn't seem to make much difference):

var wildSingleTile = new OpenLayers.Layer.WMS(
    "Wilderness Areas", 
        LAYERS: 'OR_wild_wkspc:OR_Wilderness',
        STYLES: '',
        transparent: true,
        format: 'image/png8'
    },{singleTile: true, isBaseLayer: false} 

I realize that Amazon's micro instance is not the speediest thing in the world, but I don't think it should be THIS slow.

I am quite the noob at just about everything here, including JavaScript and Linux, so any tips and suggestions would be appreciated!

P.S. Sorry for the hideous layer colors, it's not final...

  • After making a few of these changes, performance is great, but only for the first few actions or so (i.e. zooming/panning). After that it gets very, very slow. It's like GeoServer can only handle a few requests, then it's done. Any thoughts? If it helps, I've been seeing a lot of these errors in my GS logs: ERROR [geoserver.ows] - org.geoserver.platform.ServiceException: This requested used more time than allowed and has been forcefully stopped. Max rendering time is 60.0s
    – abettermap
    Feb 9, 2012 at 23:56
  • And in my catalina.out log: SEVERE: The web application [/geoserver] created a ThreadLocal with key of type... and SEVERE: The web application [/geoserver] appears to have started a thread named [GWC DiskQuota Usage Stats Gathering Thread-1] Any relationship between these and the GS error?
    – abettermap
    Feb 10, 2012 at 0:04

5 Answers 5


There are quite a few possible issues:

  1. are you reprojecting your data or is it stored in 900913? (it will be faster without the reproject).
  2. That's a pretty large map you are generating so with limited memory you may well be running into issues - look at using tiling and GWC to save redrawing the tiles each time.
  3. if those doen't help then I suspect you need to add more memory.

It's possible there are other issues with styles and layouts but the site isn't currently working so I can't check.

  • Initially my layers were in EPSG:2992, but I am in the process of projecting them all to what ESRI calls Web Mercator, which should hopefully be equivalent to 900913, and then re-uploading them to Geoserver. I've also been using GWC on them, so that should help. Thanks!
    – abettermap
    Feb 9, 2012 at 23:51

I've noticed that Geoserver is missing Native JAI ImageIO (Installation outlined here). When native JAI is available Geoserver reports:

Native JAI ImageIO  true 

This should make a great difference in performance and help you squeeze more out of the box.

Let us know how it goes.

  • It took some doing, but I got it installed. Thanks for the tip!
    – abettermap
    Feb 9, 2012 at 23:48

Beware of micro instances. Their performance is not consistent. They may be relatively fast for short periods of time and very slow after it.



This is an interesting question as I am experiencing it as well but I am not using AWS (Linux), although I did consider it. We use Dedicate Hyper-V instances (Win2008 R2) and what is of particular interest is the inconsistent performance you mention. Sometimes it is great then for no apparent reason it slows down significantly.

Everything we do is in WGS84 (EPSG:4326) so I have not had any experience with re-projecting.

I do suspect that poor disk performance on the Virtual Servers (Database and Disk Caches) may contribute to a some degree, based on some advice from our hosting provider.

Our solution, hopefully, based on answers to other questions I have posted is to roll out a standalone GeoWebcache as a front end to multiple Geoserver Instances. I'm told that GeoWebCache can handle a huge load and it is just serving cached tiles. This may work for you.



I had the same sort of issues. I increased the JVM options to start with but ultimately increasing my amazon instance to a small rather than micro did the power of good, nearly triple the memory of the micro.

The jvm and geoserver optimisations only go so far and they're worth doing but ultimately having the power of a better instance makes almost all of this go away.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.