I've now identified the problem causing the slow WFS performance. As
Andrea suspected, it is in the ArcSDEQuery.calculateResultCount() method,
called before the WFS query queries the data. The issue is that (on our
Oracle SDE instance at least) the SeQuery.calculateTableStatistics() call
is extremely slow (likely it is doing a full table scan rather than using
the spatial index).
This shows up very obviously in our case, since we have a layer with 11M
features in it. But it's impacting performance for every WFS query (even
scans of small tables seem to be much slower than the actual data
retrieval). (This actually makes me wonder if the SDE API is pulling the
data over the wire to count it!).
Here's the actual stats from a test mockup:
Testing layer MTA_SPATIAL.MTA_MINERAL_PLACER_GRID_POLY
Fetching table stats...
Row count = 1560 ---- 955.04 s
Querying data...
Row count = 1560 ---- 2.052 s
We're going to open a ticket with ESRI about this, but I don't have much
optimism they'll do anything for us (given that the SDE API is sunsetting).
So what are the options on the GeoServer side? It might be always faster
to simply run the query twice, once to count and once for the data. In
fact, there is already code in the calculateResultCount to do this, for
Oracle versioned layers. Perhaps this should be extended for *all* Oracle
layers? (Note that I still think there may be a bug in this code to do with
the order of API calls, but that can be fixed at the same time).
Thoughts?
In the meantime I am going to work on modifying the driver to test out this
idea (and we may just use that in production if it works out anyway).
On Tue, Mar 31, 2015 at 11:12 PM, Andrea Aime <andrea.a...@geo-solutions.it>
wrote
>
>
>
>>
>> So the question is: does the WMS path through the SDE driver result in a
>> different statement order than the WFS path? And if so, how can this be
>> fixed?
>>
>
> Hum... it may be, but a store is just a store, and
> featureSource.getFeatures(Query) is the same method.
> Maybe the contents of Query are different and this triggers a different
> code path in the store?
> One likely difference is that WFS (depending on your config and WFS
> version used) needs to perform a count before getting
> the actual data (part of the response headers), WMS does not.
>
>
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
