Snapping performance issue in version 4.19

[ljnio]

Hi all,

I had a go with the new snapping tool rolled out with version 4.19, but found although the self snapping works well, the performance is really bad when I try to snap to other feature layers.

I've tried a feature layer (something like this: https://stg-gis.mapshare.vic.gov.au/arcgis/rest/services/mapshare/PropertyAndParcel/MapServer/5), and a geojson layer (simple 4 points rectangle), but none of them works well.

The browser I used is Chrome. Once I move my cursor close to the snapping point, the screen will freeze for at least 20 seconds. I even got unresponsive page warning from Chrome.

Any ideas in terms of why this could happen?

Thanks,

Johnny

[JoseBanuelos]

Hello Keith,

Appreciate the feedback. Would you be able to share the service url for us to test? While working on this bug last release, we tested layers with millions of features, including the service from the original post here. After running our tests on the bug fix through these layers, we were comfortable enough to say that this issue was resolved.

However, you may have an example of a dataset where this is not completely resolved. Therefore, it would be very helpful if you could provide the service url if possible to test. If you don't feel comfortable posting your data here, feel free to message me directly via Esri Community.

Thanks,

Jose

[kgcroteau]

Hi Jose.

Thank you for the response.  Unfortunately, I am unable to share the map service because it is an intranet AGS service. 

 However, maybe some additional information will help:  The screenshots below show the "returnExtentOnly" request which is issued when snapping is initialized, and this appears to be the request that is causing the slowdown.

The feature count is 177,403 features - which is much lower than the numbers you had tested with.

Perhaps it is something unique to our map service or ArcGIS Server setup (v10.7.1).

Thanks,

Keith

[ThomasMahar]

Great!  Thank you for the update Jose.

Best,

Keith

[JoseBanuelos]

Hello Keith, @kgcroteau 

In version 4.20, we removed the requirement to wait for the extent to complete before we can start snapping. It is strange to see that it looks like your service is still being affected. Especially with less than 200,000 features. Are these features polylines, polygons, or points? Do you have other services experiencing this same issue?

Just to double-check. Are you currently using version 4.20, and does the layer finish drawing before you attempt to start snapping?

The server we tested with the service provided in the original post was a 10.6.1 service with nearly 4 million polygons.

Thanks,

Jose

[kgcroteau]

Hi Jose,

Thanks for the feedback.   

It is a polygon featureclass (parcels).  I don't believe there is anything particularly unique about it - but perhaps we are missing some indexing or something - which is slowing down the returnExtent call?  

I have confirmed that we are using 4.20:

In our instance, it does seem like snapping is still not operable until the "returnExtent" request is complete.

If you have any additional thoughts, please let me know.  Meanwhile we will examine the featureclass and the map service to see if it's something in our configuration.

Thanks for your help.

Best,

Keith

[JoseBanuelos]

Hello Keith, @kgcroteau 

You are welcome, and yes please take a look at maybe republishing the service. I went back and ran some testing on our test services and I was able to start snapping immediately with millions of features on a service that eventually timed out on the full extent request. Therefore, that request never completed and snapping was still possible immediately.

If republishing still doesn't resolve this, we can take our conversation via direct message on Esri Community, so I can maybe take a note of some of your service configurations.

Lastly, I setup a test sample you can use in your testing with over 1 million features. Its hosted on ArcGIS Online so its a different implementation, but in case you want to use it as a reference when testing, this would be a good example: https://codepen.io/banuelosj/pen/zYwPwVN

Thanks,

Jose

[kgcroteau]

Hi Jose,

OK, I believe we figured out why our instance was still slow.   We only had a single pooling instance configured for the map service.  So, even though the 4.20 client snapping tool no longer waits for the returnExtentOnly response, it was still unable to get responses from other required requests, because they were being blocked until returnExtentOnly  finished.

We increased the pool instances to 5 for or snapping services, and now snapping seems to initialize much faster.  

Thank you for all of your assistance with this issue!

Best,

Keith

[JoseBanuelos]

Hi Keith, @kgcroteau 

Ahhhh yes the pooling instance. This is great news! I am glad you and your team were able to resolve this. It was my pleasure to help!

Thanks,

Jose