Configuring number of init.js requests?

[JonathanTiu]

hi,

i read somewhere that the number of init.js requests that ESRi spawns is somehow related to the number of cpu cores you have. is that true? is there a way to configure or control the number of requests that esri makes?

on my laptop, i see 8 requests after the very first init.js request.

for our application we are really sensitive to what we initially download and i'm trying to investigate if there's anything further we can avoid downloading and these 8 requests are quite obvious.

[JonathanTiu]

Thanks for checking that @AndyGup  much appreciated!

i did some runs yesterday with esri 3 and did notice stalls as well so not specific to esri 4 - you're right.

Thanks.  Let me know if you come to any conclusion as to why the size of the workers jumped to 163k.

[JonathanTiu]

@AndyGup  Did you guys manage to figure out why there was an increase in the size of the workers between 4.27 and  4.28?

we've just bumped up to 4.29.  i haven't had a chance to see the sizes of the init.js requests in 4.29.

[AndyGup]

Hi @JonathanTiu  Yes, we did figure it out. It's related to fine tuning the API and how it uses workers under-the-hood. The size of the workers is just one parameter out of many that affects the initial load performance metrics. Overall, for our baseline testing apps, those metrics improved between 4.27 and 4.29.

With that said, if you have a simple, focused repro app that shows a major performance regression on the initial app load, then please open a Tech Support ticket so they can get this formally documented.

[NicolasGIS]

Hello @AndyGup and @JonathanTiu,

Thanks for raising this interesting topic.

I am facing a similar issue with a custom application built with arcgis-core 4.30 with vitejs. In my case, the issue is that there is not only the `init.js` file that is requested many times but many, many, many, many javascript files !

All files are cached and served from http/2, but even with all these performances considerations, there is still a very noticeable period with no features displayed. At startup, we end up in few seconds in the following situation with the TOC created, basemap loaded:

but in the backend, it spends its time loading several times (7) a big number of files even from the cache:

or another example:

Once it's finally done loading these files, it starts querying the ArcGIS Server to retrieve the data and features start behind displayed.

Even if these files are lightweights, I am under the impression that it has a performance impact.

Here is a small video to illustrate this phenomema:

Any idea ? Is it expected behavior ?

Thanks !

Nicolas

[AndyGup]

@NicolasGIS  my recommendation is to open a tech support ticket. That's typically the best route when you have detailed performance concerns.

Many (most?) of the cache hits that appear to be duplicates are likely related to the APIs web-workers working in parallel. Also, the browser, itself, is making parallel http requests. Oftentimes, what may seem to be sequential activity isn't necessarily so, and you have to look carefully at the network "Timing" section of the Chrome dev tools, or use a more advanced tool like Charles Debugging Proxy. Initial load time is a multi-factorial issue that includes not just the API modules, but also how the app is constructed, the data, the number and types of layers, the type of queries, how the layers are constructed, etc. I hope that helps.

[NicolasGIS]

Thanks @AndyGupfor your reply ! Much appreciated.

The app architecture and stack is fairly simple: map focused web app built with latest ESRI Maps SDK for javascript (@arcgis/core) and calcite design system. By many aspects it is similar to the new MapViewer. But it does make heavy use of custom workers as described here:

https://github.com/Esri/jsapi-resources/tree/main/core-samples/jsapi-custom-workers

All those requests delaying the initial load of the map are coming from these custom workers.

The issue does not seem to be data/map related: I can open the very same webmap in the MapViewer and this phenomena does not appear. If I check MapViewer workers requests, they are only 4:

"dojo.js, arcadeUtils.js, FeaturePipelineWorker.js, libtess.js"

MapViewer seems to be built with dojo: could it be possible that many workers scripts are bundled into the "dojo.js" build ? Like forcing it with dojo build profile or something like that ? Should we investigate something equivalent with vite maybe ?

Thanks

[NicolasGIS]

Just referencing another issue that describes pretty much what we are experiencing currently with vite as bundler but in this case it was with arcgis-webpack-plugin and Maps SDK workers:

https://github.com/Esri/arcgis-webpack-plugin/issues/73

"During runtime, when creating a new feature layer for the first time, there are more than 1500 network requests from web workers (while Chrome limits up to 6 parallel requests) -it which leads to major delay displaying the feature layer."

It is not exactly the same issue as on our side, it is our custom workers instead of the Maps SDK for javascript ones which get requested but the outcome is the same: too many requests from workers leading to delay in displaying the map.

Issue is different but it makes me think that something can be done on the bundler side to prevent this ?

[NicolasGIS]

Did some additional debugging and compare with a simple WebApp using CDN version of the SDK.

I found out that basically our workers are not "bundled" contrary to the CDN version.

As a consequence, initializing the worker "FeaturePipelineWorker", triggers the requests of all the dependencies of this module and there are a lot:

While using in the CDN version, I can see that all these dependencies are bundled in "FeaturePipelineWorker.js". Do you make maybe a separate bundles of all modules of "esri/core/workers/registry" by any chance ?  I am still wondering why vite does not do that by default.

[AndyGup]

@NicolasGIS  please provide a minimal reproducible app so that we can analyze the issue. Here are the guidelines: https://developers.arcgis.com/javascript/latest/troubleshooting/#minimal-reproducible-application.

[NicolasGIS]

Thanks for your feedback @AndyGup .

It is visible on your core samples from "js-api-resources" repository:

https://github.com/Esri/jsapi-resources/tree/main/core-samples/jsapi-custom-workers

Run 'npm install', 'npm run build' and serve the build.

You end up with the phenomena described: many requests to individuals workers' dependencies modules.

Don't need to click on "Run spatial Join" to run the custom worker.

Basically, as soon as you make use of custom workers with core, you end up with the phenomena described that is to say loading all the depencies of ESRI Maps SDK workers individually (mainly FeaturePipelineWorker dependencies for simple webmap).

If you compare with a CDN version of the app:

require(["esri/Map", "esri/views/MapView", "esri/layers/FeatureLayer", "esri/widgets/Legend"], (ArcGISMap, MapView, FeatureLayer, Legend) =>{
    const cityLayer = new FeatureLayer({
        portalItem: {
          id: "e39d04981238498792eb33ea26ba1c09"
        }
      });
     
      const frsLayer = new FeatureLayer({
        portalItem: {
          id: "cdff193a3e3743a5bc770e2743f215b3"
        }
      });
     
      const map = new ArcGISMap({
        basemap: "dark-gray-vector",
        layers: [cityLayer, frsLayer]
      });
     
      const view = new MapView({
        container: "viewDiv",
        map,
        center: [-117.98, 33.96],
        zoom: 12
      });
     
      const legend = new Legend({ view });
      view.ui.add(legend, "top-right");
})

all the worker code is bundled in 'https://js.arcgis.com/4.31/esri/views/2d/layers/features/FeaturePipelineWorker.js' 

and there much much less requests: