On Fri, Feb 15, 2013 at 3:49 PM, Jürgen Weichand <
[email protected]> 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
--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==
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
-------------------------------------------------------
------------------------------------------------------------------------------
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
is your hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials, tech docs,
whitepapers, evaluation guides, and opinion stories. Check out the most
recent posts - join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Geoserver-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
