On Fri, Feb 15, 2013 at 3:49 PM, Jürgen Weichand <juergen.weichand@anonymised.com> wrote:
More detailed log file (with sql-statements):
http://geoserv.weichand.de/tmp/sqllog.txt
Runtime of the count-statement(s) on huge tables/views (~10.000.000 features)?
Needed for paging?
Yes, it’s needed for paging.
However the attribute is optional, we could avoid returning it and thus computing it,
we just lack the configuration to do so (would be similar to the feature bounds one,
which I guess you already disabled, as I don’t see a bounds query in your SQL logs).
I’ve tried to get a local setup to reproduce some of your results.
To that end, I’ve downloaded the buildings layers for a good portion of Germany
from Geofabrik (http://download.geofabrik.de/openstreetmap/europe/germany/)
and loaded them in PostGIS, getting a buildings layer with around 8 million features.
These layers are in 4326, so I’ve reprojected your bounding boxes in 4326, getting
11.386153034926789,47.913610526723836
11.852600617836472,48.30077117627526
(lon/lat order), which applied to the data gives me back 170020 results, smaller
than yours, but in the same order of magnitude: the size of the returned GML
varies according to the version, but it’s around the 100MB.
I’ve run the requests in XML you provided, adapting them to my typename and
coordinate system, using curl with a template that makes it return the
connection time, the time at which the first result is returned, and finally the
total time:
curl -s -o /dev/null -d @GetFeature_10_BBOX.xml -XPOST -H ‘Content-type: text/xml’ -w “%{time_connect}:%{time_starttransfer}:%{time_total}” “http://localhost:8080/geoserver/wfs”
0,001:0,086:4,411
curl -s -o /dev/null -d @GetFeature_11_BBOX.xml -XPOST -H ‘Content-type: text/xml’ -w “%{time_connect}:%{time_time_total}” “http://localhost:8080/geoserver/wfs”
0,000:0,211:45,496
curl -s -o /dev/null -d @GetFeature_20_BBOX.xml -XPOST -H ‘Content-type: text/xml’ -w “%{time_connect}:%{time_time_total}” “http://localhost:8080/geoserver/wfs”
0,001:0,002:59,891
While the time to return the full GML file varies a lot (the GML 3 encoders are quite inefficient),
the time to get the first result is negligible in all three cases.
And this is with the default settings, I haven’t even disabled the “feature bounding” option,
so the above also includes the time it takes to run the select for the bounds of the returned
feature collection.
Ah, I’ve run the tests with the GeoServer 2.3.x series (the 2.2.x one is coming to an end,
probably next week, next month the latest).
Cheers
Andrea
–
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it