Proposal: bomb-workers add upper limit

[camillobruni]

Bomb-workers currently spawns 26 workers in parallel.
This is a highly unrealistic scenario, google maps for instance roughly limits itself to 4 workers (even on high end machines).

This PR proposes an upper limit on number of workers.
This way we still have some focus on Worker startup performance while not heavily over indexing on an unrealistic usecase.

Happy to hear feedback.

[netlify]

✅ Deploy Preview for webkit-jetstream-preview ready!

Name	Link
🔨 Latest commit	86796ea
🔍 Latest deploy log	https://app.netlify.com/projects/webkit-jetstream-preview/deploys/688a359c197431000845865c
😎 Deploy Preview	https://deploy-preview-106--webkit-jetstream-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[iainireland]

I agree that well-designed sites should probably not spawn this many workers. On the other hand, I expect that real-world websites often do spawn a lot of threads. For example, Keith mentioned in Slack that Photoshop spawns 30+ workers.

The more workers we spawn, the more this benchmark is "about" the overhead of worker startup. Given that the actual work being performed in each of these threads is uninteresting, maybe that's not a bad thing.

I could go either way on this.

[camillobruni]

This is the first time I hear about 30+ workers for photoshop. I know that maps heavily limited their page to max ~8 workers since it was just not efficient beyond that point.

Beyond that I don't have any data point on how many workers are realistic for a page.

[Constellation]

Yeah, it seems that Photoshop is launching more than 40 workers, in both Safari and Chrome. I would like to keep this test as is since we are observing these use cases. segmentation is doing the other worker tests, so I would like to leave this test to check the performance for that kind of pattern to keep the coverage of the tests (like, more than 40 workers etc.).

[camillobruni]

Analysing photoshop web, we do see 30+ workers being created. At the average rate of 8 / s, which roughly matches window.navigator.hardwareConcurrency == 8 (not sure how much this differs in other browser/machines).

So I agree that spawning more that 8 workers is a valid use-case, but maybe not at the rate the current benchmark does.
However, we do see some code being run in parallel on and off on the 30 workers, that part does seem to be realistic.

[camillobruni]

Closing this PR in favour of #125