0

I face a speed issue related to GeoServer. More specifically in my web application when I click the following URL, it takes several seconds in order for the browser to receive the file. This happen with files which are of the size of 60mb or more.

http://domain?format_options=charset:UTF-8&typename=workspace:layer_name&outputFormat=SHAPE-ZIP&version=1.0.0&service=WFS&request=GetFeature

I tried to check the log file of GeoServer, by setting the logging to developer option. The only warnings I got are the following and I don't thing is related to this:

2017-05-09 15:04:04,491 DEBUG [org.geoserver.web] - cannot convert url: jar:file:/home/sdi/tomcat/webapps/geoserver/WEB-INF/lib/gs-web-core-2.5.1.jar!/org/geoserver/web/css/blueprint/print.css to file (URI is not hierarchical), falling back to the inputstream for polling
2017-05-09 15:04:04,491 DEBUG [org.geoserver.web] - cannot convert url: jar:file:/home/sdi/tomcat/webapps/geoserver/WEB-INF/lib/gs-web-core-2.5.1.jar!/org/geoserver/web/css/geoserver.css to file (URI is not hierarchical), falling back to the inputstream for polling
2017-05-09 15:04:04,491 DEBUG [org.geoserver.web] - cannot convert url: jar:file:/home/sdi/tomcat/webapps/geoserver/WEB-INF/lib/gs-web-core-2.5.1.jar!/org/geoserver/web/css/blueprint/ie.css to file (URI is not hierarchical), falling back to the inputstream for polling
2017-05-09 15:04:04,492 DEBUG [org.geoserver.web] - cannot convert url: jar:file:/home/sdi/tomcat/webapps/geoserver/WEB-INF/lib/gs-web-core-2.5.1.jar!/org/geoserver/web/js/jquery-1.2.6.min.js to file (URI is not hierarchical), falling back to the inputstream for polling
2017-05-09 15:04:04,492 DEBUG [org.geoserver.web] - cannot convert url: jar:file:/home/sdi/tomcat/webapps/geoserver/WEB-INF/lib/gs-web-core-2.5.1.jar!/org/geoserver/web/js/jquery.inline-info.js to file (URI is not hierarchical), falling back to the inputstream for polling

I wonder if this is an issue of the tomcat configuration. Perhaps increasing the heap memory would speed things up? Do you have any recommendation on this or hint what could cause this slow behaviour?

2

When using shape-zip GeoServer has to write the shapefile on disk, then create a zip out of it and send it back. The client does not see a response coming back until the zipping starts and the write is finalized, and there is nothing that can be done to avoid it.

That said, 60 seconds for a 60MB (uncompressed) shapefile seems like a lot of time.

  • Wow! I didn't know that. It takes around 10-15 seconds (not 60). But I get the same behavior for KML etc. Can this be related to heap memory? Should I try to increase it? – user1919 May 9 '17 at 15:49
  • 1
    KML should start streaming right away, it only has to wait for the data source to start returning records. I would not expect memory to make much of a difference. What about GML, is that fast? If not, look in your data source, it might take time to return the records for whatever reason... the output is shapefile, what about the input? – Andrea Aime May 10 '17 at 6:35
  • GML is also slow.. My input is a postgres. I have a store in geoserver which points to the postgres db. My tables are indexed and the db is in the same server. Any hint what I should check? – user1919 May 10 '17 at 7:36
  • One extra piece of information: My layer in geoserver is created as SQL View. Could that slow things down? – user1919 May 10 '17 at 7:53
  • 1
    So I run the same query in postgres and it takes..ages. So its a database issue.. – user1919 May 10 '17 at 11:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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