ArcGIS JavaScript 4.x Slow Performance

[dimesv]

Hi guys,

I have a a web map with a few layers in ArcGIS Enterprise 11.3 (also tested in 11.5), and I am using the ArcGIS JavaScript API 4.33 (latest) to display the map and it draws really slow when zooming and panning. I have similar performance when using the Portal for ArcGIS Map Viewer or when using the load web map sample available in the ArcGIS Maps SDK for JavaScript web site.

Issue:

From what I can see the app does not seem to be caching anything client-side. At least, this is the feeling I get. I was expecting the Feature Layer to cache the data it obtained when loading and not issuing additional requests unless the extent is changed. When I zoom in further, i continue to see HTTP requests going through to ArcGIS Server. This results in slow performance as it requests ArcGIS Server for data and then the renderer redraws the symbols causing it to flicker at times.

Comparison:

I have opened the exact same web map in Sweet for ArcGIS (which uses the ArcGIS JS API) and it draws at least 10x times faster. This is a big difference. Not only the load time is faster but zooming and panning is miles better. I have inspected the HTTP request/response for details and these are the only differences I can find:

Sweet

f: pbf
geometry: {"xmin":18733798.3883425,"ymin":-5853241.87796104,"xmax":18736244.373247623,"ymax":-5850795.893055916}
maxAllowableOffset: 0
orderByFields: OBJECTID ASC
outFields: *
outSR: 102100
quantizationParameters: {"mode":"edit","originPosition":"upperLeft"}
resultType: standard
spatialRel: esriSpatialRelIntersects
where: 1=1
geometryType: esriGeometryEnvelope
inSR: 102100

ArcGIS Maps SDK for JavaScript

f: pbf
geometry: {"xmin":18735632.877028253,"ymin":-5850184.396829739,"xmax":18735938.625141393,"ymax":-5849878.648716599}
orderByFields: OBJECTID
outFields: OBJECTID,Subtype
outSR: 102100
quantizationParameters: {"extent":{"spatialReference":{"latestWkid":3857,"wkid":102100},"xmin":18735632.877028253,"ymin":-5850184.396829739,"xmax":18735938.625141393,"ymax":-5849878.648716599},"mode":"view","originPosition":"upperLeft","tolerance":0.5971642834777837}
resultType: tile
returnCentroid: true
returnExceededLimitFeatures: false
spatialRel: esriSpatialRelIntersects
where: 1=1
geometryType: esriGeometryEnvelope
inSR: 10210

Additionally, I have customized the properties of the layer and set the same resultType and maxAllowableOffset but it didn't work either. I have not found a way to change the property "quantizationParameters" though.

I don't think these parameters are the issue. What Sweet for ArcGIS seems to be doing differently is that it only issues new HTTP requests WHEN the extent changes. Until then, it has everything required client-side. I don't have any layer configured to refresh the data periodically so I don't understand why things can't be cached client-side like Sweet does. I understand that some types of layer may require something more dynamic like Stream Layers but in most cases I can think of we don't require this behavior. If we want the latest data we simply refresh the page.

The Feature Layer does not seem to honor what I would expect when the mode is set to Snapshot or On-Demand, which i tried to set at the web map level but it also didn't change things.

Any idea how to improve performance here?

Many thanks,

Jose De Sousa

[JonathanDawe_BAS]

The ArcGIS JS API definitely works much better with graphics hardware. Its relying on WebGL unlike the previous iterations which were not using the webgl and instead using DOM element manipulation directly. Most modern libraries are moving this way, but if you need something more light weight you can use something like leaflet. 

Its a pretty difficult comparison to make, there are huge performance benefits to utilising modern webgl. It would literally be impossible to render a million points in the DOM... but it does set the minimum spec to get smooth operation much higher! 

[SebastianKrings]

Another thing we just discovered is bridging between IP v4 and v6.
When running our app on development machines (Win11) using localhost its slowing down because Windows translates this to ::0.
When explicitly using 0.0.0.0 it becomes pretty fast because this way IP v4 is explicitly given and used while localhost bridges from v6 to v4 first.

This is not a problem on our production system where we use hostnames which resolve to ip v4.

In the network tab of dev tools in the browser will show you, how long the http requests will take.
When you subtract this time from the overall time you can differentiate between loading and rendering timings. This could help solving your problem.

[dimesv]

I have found that performance boosts significantly if we disable the following capabilities on the feature service: Create, Update and Delete. The reason is that quantization is no longer used. This doesn't work as a fix but it can help in scenarios where we can swap between two web maps: one for viewing, and another one for editing. The difference is substantial and it does reduce the load on the backend as data is cached client-side. The same happens if we add a readonly layer e.g. /MapServer/0 to a webmap.

It would be nice to see this improvement coming traditional feature services also:

• https://developers.arcgis.com/documentation/portal-and-data-services/data-services/feature-services/...