topic Re: Configuring number of init.js requests? in ArcGIS JavaScript Maps SDK Questions

Configuring number of init.js requests?

JonathanTiu — Mon, 06 Nov 2023 17:23:43 GMT

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.

Re: Configuring number of init.js requests?

AndyGup — Mon, 06 Nov 2023 18:08:57 GMT

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?

Re: Configuring number of init.js requests?

JonathanTiu — Mon, 06 Nov 2023 18:14:39 GMT

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?

Re: Configuring number of init.js requests?

AndyGup — Mon, 06 Nov 2023 18:46:23 GMT

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:

Re: Configuring number of init.js requests?

JonathanTiu — Tue, 07 Nov 2023 01:04:26 GMT

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?

Re: Configuring number of init.js requests?

JonathanTiu — Tue, 07 Nov 2023 07:24:50 GMT

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

Re: Configuring number of init.js requests?

AndyGup — Tue, 07 Nov 2023 16:02:52 GMT

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?

Re: Configuring number of init.js requests?

AndyGup — Tue, 07 Nov 2023 17:49:51 GMT

@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.

Re: Configuring number of init.js requests?

JonathanTiu — Tue, 07 Nov 2023 18:10:29 GMT

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?

Re: Configuring number of init.js requests?

AndyGup — Mon, 13 Nov 2023 21:24:43 GMT

@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.

Re: Configuring number of init.js requests?

JonathanTiu — Tue, 21 Nov 2023 01:53:07 GMT

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.

Re: Configuring number of init.js requests?

JonathanTiu — Tue, 02 Apr 2024 23:21:27 GMT

@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.

Re: Configuring number of init.js requests?

AndyGup — Wed, 03 Apr 2024 22:46:23 GMT

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.

Re: Configuring number of init.js requests?

NicolasGIS — Tue, 05 Nov 2024 08:06:14 GMT

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:

(view in My Videos)

Any idea ? Is it expected behavior ?

Thanks !

Nicolas

Re: Configuring number of init.js requests?

AndyGup — Wed, 13 Nov 2024 17:59:19 GMT

@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.

Re: Configuring number of init.js requests?

NicolasGIS — Fri, 29 Nov 2024 17:38:10 GMT

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

Re: Configuring number of init.js requests?

NicolasGIS — Tue, 03 Dec 2024 10:42:11 GMT

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 ?

Re: Configuring number of init.js requests?

NicolasGIS — Tue, 03 Dec 2024 12:58:58 GMT

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.

Re: Configuring number of init.js requests?

AndyGup — Tue, 03 Dec 2024 19:55:03 GMT

@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.

Re: Configuring number of init.js requests?

NicolasGIS — Wed, 04 Dec 2024 13:14:49 GMT

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: