[wasm] Setting `maxParallelDownloads` sometimes has no effect

[MackinnonBuck]

Summary

Configuring maxParallelDownloads via the dotnet JS API sometimes doesn't have an effect, and WebAssembly resources are still downloaded with maximal parallelism.

Description

I found this issue when attempting to throttle WebAssembly resource downloads in a Blazor Web app to see how the throttling affected websocket connection quality. Locally, I was able to fix the problem my changing an == to a >= on this line:

runtime/src/mono/wasm/runtime/loader/assets.ts

Line 452 in 2a6bd3a

if (parallel_count == loaderHelpers.maxParallelDownloads) {

I wasn't able to fully debug the underlying cause of the issue, but I believe what happens is the value for loaderHelpers.maxParallelDownloads has its default value of 16 for the first asset or so, but then later respects the value provided via builder.WithConfig(). So if the configured limit is less than 16, the case where the number of current downloads is exactly the configured limit might be skipped, which causes unbounded parallelism.

Steps to reproduce

1. Create a Blazor Web App with "Auto" interactivity
   • e.g., dotnet new blazor -int Auto
2. Replace the blazor.web.js script reference in App.razor with the following:

   <script src="_framework/blazor.web.js" autostart="false"></script>
   <script>
       Blazor.start({
           webAssembly: {
               configureRuntime: (builder) => {
                   builder.withConfig({
                       maxParallelDownloads: 1,
                   });
               },
           },
       });
   </script>

3. Run the app with Microsoft Edge as the selected browser
4. In the browser's dev tools, go to the "Network" tab and select "Fast 3G" throttling (to make it easier to see the parallelism)
5. With the dev tools window left open, navigate to the Counter page
6. Observe that WebAssembly resources are downloaded in parallel

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Summary

Configuring maxParallelDownloads via the dotnet JS API sometimes doesn't have an effect, and WebAssembly resources are still downloaded with maximal parallelism.

Description

I found this issue when attempting to throttle WebAssembly resource downloads in a Blazor Web app to see how the throttling affected websocket connection quality. Locally, I was able to fix the problem my changing an == to a >= on this line:

runtime/src/mono/wasm/runtime/loader/assets.ts

Line 452 in 2a6bd3a

if (parallel_count == loaderHelpers.maxParallelDownloads) {

I wasn't able to fully debug the underlying cause of the issue, but I believe what happens is the value for loaderHelpers.maxParallelDownloads has its default value of 16 for the first asset or so, but then later respects the value provided via builder.WithConfig(). So if the configured limit is less than 16, the case where the number of current downloads is exactly the configured limit might be skipped, which causes unbounded parallelism.

Steps to reproduce

1. Create a Blazor Web App with "Auto" interactivity
   • e.g., dotnet new blazor -int Auto
2. Replace the blazor.web.js script reference in App.razor with the following:

   <script src="_framework/blazor.web.js" autostart="false"></script>
   <script>
       Blazor.start({
           webAssembly: {
               configureRuntime: (builder) => {
                   builder.withConfig({
                       maxParallelDownloads: 1,
                   });
               },
           },
       });
   </script>

3. Run the app with Microsoft Edge as the selected browser
4. In the browser's dev tools, go to the "Network" tab and select "Fast 3G" throttling (to make it easier to see the parallelism)
5. With the dev tools window left open, navigate to the Counter page
6. Observe that WebAssembly resources are downloaded in parallel

Author:	MackinnonBuck
Assignees:	-
Labels:	bug, arch-wasm, untriaged, needs-area-label, os-browser
Milestone:	-

[radical]

cc @pavelsavara @maraf

[pavelsavara]

how the throttling affected websocket connection quality.

It is unrelated, except it uses same bandwidth, right ?

but then later respects the value provided via builder.WithConfig().

It's set in mono_download_assets and I guess we could move it earlier to mono_wasm_load_config
Which is before start_asset_download_with_throttle was ever called, and so parallel_count would be 0

I was able to fix the problem my changing an == to a >=

we don't want to create multiple instances of throttlingPromise at the same time I think.

[MackinnonBuck]

It is unrelated, except it uses same bandwidth, right ?

Right, I was testing if reducing the bandwidth occupied by WebAssembly resource downloads would improve the quality of the websocket connection (and my results indicate that it does make a difference).