Select to view content in your preferred language

ArcGIS 4.2x now much slower to fetch and draw service layers with millions of records

4032
13
Jump to solution
01-24-2022 05:06 PM
RyanSutcliffe
Frequent Contributor

Looking at moving from 4.19 to 4.21+ and ran into a problem loading FeatureLayers from our backend ArcGIS Server REST MapServices. At 4.21 loading point layers with over a few million records becomes really slow on initial load. The time from initial request to draw went from a couple seconds or less to 30+ seconds. 

 When I watch the network traffic I can see that as of 4.21 there is now an initial fetch for the count of records with params like so: 

 

 

 

`returnIdsOnly=true&returnCountOnly=true&spatialRel=esriSpatialRelIntersects&where=1%3D1`

 

 

 

 

This is returning the count of the records in the service layer and it consistently takes our server over 30 seconds to process.

The release notes for ArcGIS 4.21 say:

At version 4.19, we improved the performance of point FeatureLayers hosted on ArcGIS Online. Version 4.21 brings these changes to ArcGIS Enterprise point services.

It looks like this fetch of the count is part of a trick to try to speed up subsequent requests. As an aside we haven't noticed any improvement for any of our datasets/apps on subsequent fetches/draws either.

 

Some details:

Our point layer(s) come from an SDE Database Feature Class layer. The MapService is not cached. ESRI Canada technical support have confirmed they have been able to reproduce this problem with other large datasets of their own. 

For our large datasets our use case is that these layers are configured to only draw at a very large scale where a couple thousand records draw at a time. Note that in the use case that ESRI demonstrates in their 4.19 release notes shows all the data drawn at once at full scale. I think their trick might provide advantages in that use case at the detriment of my own.

I would like this performance improvement approach to be opt-in in the API (Feature Idea) since ESRI won't consider it a bug.

I am also interested if users here know of tricks to speed up getting the recordCount of a large dataset via REST.  For example I can get the recordCount via a direct SQL request to the database table in less than 2 seconds. Why does it take suddenly 30 seconds for ArcGIS Server? Is there some trick or optimization to cache this? 

 

0 Kudos
13 Replies
mgeorge
Esri Contributor

@RyanSutcliffe, just talked to the dev for the npm build. It should work the same way. You just need to include

<script>

window.dojoConfig = {

  has: { "featurelayer-snapshot-enabled": 0 }

}

</script>

before the API gets loaded.

 

UndralBatsukh
Esri Regular Contributor

Hi @RyanSutcliffe 

So I am in search of a service that exhibits the behavior you describe. I haven't been able to reproduce the behavior your described above. 

Could you please give me more details on your map service. What version of the server are you using? Would it be possible to give me a contact info of the support analyst who was able to reproduce this issue? 

 

Thanks,

0 Kudos
RyanSutcliffe
Frequent Contributor

Hi @UndralBatsukh , I sent you, via DM, the ESRI Support Case #. There are some details on our setup in that if you are able to access. Our services aren't public so I can't share a link. I haven't looked at this in a while as the dojoConfig workaround allowed us to get around the issue.
[update: checked if this behavior still happens this morning at 4.25. It does. Details:
- load a MapService's point layer (not cached) into a FeatureLayer. Layer configured not to be visible until 1:2k but the count query will run when layer is loaded and fetch the count for the layer (in this case about 4million records). This fetch takes about 20s.]

0 Kudos
RyanSutcliffe
Frequent Contributor

I just realized that I seem to be sometimes having the same problem when creating a SceneView and the above doesn't fix it there. I've created a new Post for help with this.

0 Kudos