nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Find more posts tagged with

Accepted answers

All comments

AndyGup

@NicolasGIS as you noted, there isn't a 1:1 relationship between the AMD CDN and a local build of the "@arcgis/core" ES modules. Those use two different module systems, so comparing them side-by-side will always result in different performance profiles.

In reviewing the jsapi-custom-worker sample, the network requests and overall performance appear to be working as-designed for "@arcgis/core". I tested the sample locally on my laptop using 4.31, and I didn't see any http request browser stalls. There's definitely a pause when the spatial-join.worker runs, but that's also expected. As I mentioned above, you'll need to use a tool such as Charles debugging proxy to help distinguish between actual http requests and requests are cached by the browser. The chrome developer console tools aren't always telling the full story.

Some things you can do on your end to ensure the best performance when building the SDK locally:

Host your local build on a CDN
If you are hosting the build on your own web server:
- Make sure your web server is using HTTP/2
- If using HTTP/1 set the “Keep-Alive” header

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:

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

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.

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

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

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

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

@JonathanTiuI I verified in Charles while using Chrome that the SDK's wasm requests are being correctly cached. Chrome 119 dev tools appear to be incorrectly reporting cached file requests as HTTP 200s. Here's a screenshot:

Also, the wasm scripts are being loaded correctly (synchronously). This is the pattern defined by the WorkerGlobalScope of the browser's Web Workers API,. More information is available on MDN here: https://developer.mozilla.org/en-US/docs/Web/API/WorkerGlobalScope/importScripts. As you may know, when stalls are reported in the network tab of the dev console, they can be the result of many different factors. Taking that into account, I didn't see anything unusual after multiple tests.

We will continue to investigate the size of the workers.

JonathanTiu

yes it seems the size increase is roughly 40k or so. so in our case with 8 requests, that's an extra 300k plus we're transferring.

i just ran again this morning our app with 4.28. i'm not seeing long stall times but i am seeing long server response times. below is screenshot of the 8th request. each request to https://js.arcgis.com/4.27/esri/core/workers/init.js, the server response wait time gets longer until it reached the peak (of 211ms) in the 8th request. Something bottlenecking?

AndyGup

@JonathanTiu with regards to the increased init.js request times, thanks for the information. That might be related to a size increase in the worker between 4.27 and 4.28. I can also repro dev tools reporting the init.js requests being stalled when caching is enabled. We need to do some research. I'll open an issue pending some initial investigation. It's not clear what's actually happening versus what might be misreported in dev tools, e.g. 200 vs 304 status response codes.

AndyGup

Hi @JonathanTiu, you should only see the first request to https://js.arcgis.com/4.28/esri/core/workers/init.js, depending on how you've configured Charles. You shouldn't see any other subsequent requests to the same modules, e.g. init.js. If the browser is caching correctly, there will only be that one request, confirming that browser caching is working correctly. Did that make more sense?

JonathanTiu

The reason i'm scrutinizing this so closely is because since we moved to 4.28, i've noticed we've gotten slower and i can see these 8 init.js requests get progressively slower. you can see they are stalled for long periods of time - over 100ms. That's huge.

Whereas in 4.27, we have the same 8 init.js requests but the longest any request has to wait is around 14ms. Absolute huge difference. I also notice the init.jst requests are launched earlier in 4.27. in 4.28 they seem to be launched later which further adds to the delay i'm seeing in our app

JonathanTiu

thanks @AndyGup ! Silly question as i've never used Charles proxy before.

i refrehsed my app so it downloaded esri 4.28 again.

i then looked at the charles proxy. where do i look to see if the init.js requests are cached? i see js.arcgis.com so i expanded that node....

i'm trying to find the https://js.arcgis.com/4.28/esri/core/workers/init.js requests right?

AndyGup

Yes, you can use Charles debugging proxy to determine if the requests are being cached for "/esri/core/workers/init.js". Also important, make sure you have unchecked "Disable caching" in the dev tools Network tab.

When the browser is correctly reporting worker caching, you will see at least three HTTP requests to "init.js" in the browser console:

First - https://js.arcgis.com/4.28/init.js (HTTP 200)

Second - https://js.arcgis.com/4.28/esri/core/workers/init.js (HTTP 200)

Third - https://js.arcgis.com/4.28/esri/core/workers/init.js (HTTP 304)

Here's a screenshot from Safari, as an example:

JonathanTiu

i see so you're saying the first init.js should have been cached as a 304 so it won't ask for those resources again. so i shouldn't be seeing this many init.js requests?

from what i see they're all reported as 200s. so what do i need to do to verify on my side they are actually 304s? install the Charles debugging proxy?

AndyGup

Hi @JonathanTiu , yes without getting into all the details, generally speaking the number of worker requests (e.g. init.js) spawned at startup is related to the number of CPUs.

Perhaps more importantly for your situation, we have previously investigated the browser caching of workers, which is related to the init.js requests you are seeing. We discovered that devtools (e.g. Chrome and Firefox) has misreported subsequent worker requests as HTTP 200's. We had to use Charles debugging proxy to verify they were actually being correctly cached as 304s. I don't currently have it installed but I can install/retest on our end. I did just notice that Safari is correctly reporting 304s.

Is this something you can double check on your application?

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.