Hi,
I dont know what to do. I'm getting extremely laggy responses from Geocoder. 8 seconds for one request is typical (EG shown below). The maps Im requesting are not simple ones. The contain up to 16 layers requested from a PostGIS database with moderate to high level of styling. Im running geoserver 1.5.0-RC4 on Tomcat 5.5 as a deployed war. Currently Im running it on my Ubuntu-Dimesion 3000 with 2GB ram. I was running it on one of our best boxes but it kept taking the whole system down. Were still not sure really why that is but believe it was getting over loaded with requests and database connections.
How can I best optimize geoserver? 8 seconds is pitiful for our needs, let alone if we were to send multiple requests at the same time. I really think I need to shave off 5 seconds before it is usable and we really do want to use it. The maps that it produces are so clean in contrast to Mapsever (what we are currently using).
Any information would be much appreciated...
---(EG. Sample Map request and time stamps)---
...
443725 [INFO] org.vfny.geoserver.servlets.AbstractService - handling request: org.vfny.geoserver.wms.requests.GetMapRequest@anonymised.com
451568 [INFO] org.vfny.geoserver.servlets.AbstractService - Service handled
...
Martin Vivian
Software Developer
LISAsoft
Martin Vivian ha scritto:
Hi,
I dont know what to do. I'm getting extremely laggy responses from Geocoder. 8 seconds for one request is typical (EG shown below). The maps Im requesting are not simple ones. The contain up to 16 layers requested from a PostGIS database with moderate to high level of styling. Im running geoserver 1.5.0-RC4 on Tomcat 5.5 as a deployed war. Currently Im running it on my Ubuntu-Dimesion 3000 with 2GB ram. I was running it on one of our best boxes but it kept taking the whole system down. Were still not sure really why that is but believe it was getting over loaded with requests and database connections.
How can I best optimize geoserver? 8 seconds is pitiful for our needs, let alone if we were to send multiple requests at the same time. I really think I need to shave off 5 seconds before it is usable and we really do want to use it. The maps that it produces are so clean in contrast to Mapsever (what we are currently using).
Hum, from what you say it seems GeoServer is spending lots of time
gathering data from postgis and rendering it. Fancy styling is usually
one of the biggest slowness causes, text halos, transparencies, symbolizers that do directly depend on attributes are the major causes
of slowdown (sometimes you can make an equivalent styling by using
multiple rules and static symbolizers, and it's faster).
Yet, what you say make me wonder: what do you mean by taking down the server? Is it making Postgres go down? Is the whole process CPU bound,
and if so, who's consuming the CPU? (I assume it is, but it may be that it's waiting for data to come down the network instead).
Oh, sorry for the dumb question, but all geometry columns are spatiall
indexed, and you did run a vacuum analyze at least once lately, right?
The same goes for all columns that could be used in predicates during
data gathering (you can go to the server section, in the configuration
panel, and up the logging level to FINE to see which queries are
being performed, and if you look at the GeoServer log when making
requests, that may give you a hint on whether the slowness is due
to database access or by map rendering).
To really give you good information I would need a dump of the data
and styles to replicate your issues and fire up a profiler to check
what's going on... It's hard to tell exactly were the issues are
otherwise.
Cheers
Andrea
Martin Vivian ha scritto:
Andrea Aime wrote:
...
Thank you for the sujestions. Thanks to the FINE level logging I was able to identify one layer that was taking 6 seconds alone. I am currently taking action to optimize this layer. In regard to our server that geoserver was taking down, I really dont know what happened. We had to keep restarting tomcat and manually killing some database connections. Or something like that. Im hoping with the new optimizations we can make things go a lot smoother.
Cool. If the layer it's taking so long, may it be that you're trying to
draw too many features when too zoomed out? On sigma.openplans.org
we had a few very expensive layers, such as the road network. To
tame drawing times we took a few steps:
* when very zoomed out, draw only highways
* increase the class of road that gets shows when zoomin in
* have not one but three geometric columns in those tables, one with the
full geometry, the other two with progressively simplified versions of
the original that we use when the zoom level does not need that much
precision (GeoServer does on the fly generalization before drawing,
but it takes some work to do that anyways, having pre-generalized
geometries helps both the CPU and the transfer times from db to
application).
* depending on the zoom level, adopt different symbolizers, use
expensive but nice ones only when fairly zoomed in (that is, when
the number of depicted geometries is small).
This results, in the end, in a SLD file that's 2000 lines (for just one layer), but the effort pays back with better rendering times.
Hope this helps
Cheers
Andrea