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.

[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?

[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]

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]

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]

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

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

[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]

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