In it's useful for anyone, attached is a small test program that demonstrates the performance issue with computing statistics for SDE layers with spatial filters.
On Thu, Apr 2, 2015 at 10:47 AM, Martin Davis <[email protected]> wrote: > 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 < > [email protected]> 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. >> >> >>
TableStatsTest.java
Description: Binary data
------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________ Geoserver-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-users
