I have implemented a workaround for the performance issue with computing
request size in SDE on Oracle. It's here:
https://github.com/dr-jts/geotools/commit/eef7056e899660f34447f38e5b83c1c38666ff19
This has been tested in several environments and seems to work correctly in
all of them.
(Note: the workaround is currently active for Oracle only, since that's the
only SDE environment I can test. The issue might exist on other DBs as
well).
Will try and create issues for this when I can (Issue tracker seems to be
in flux right now?). I can make a pull request as well if that's
acceptable now.
On Thu, Apr 2, 2015 at 10:47 AM, Martin Davis <mtncl...@gmail.com> 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 <
> 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.
>>
>>
>>
------------------------------------------------------------------------------
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
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
