search

denoland / deno

A modern runtime for JavaScript and TypeScript.
https://deno.com
MIT License
93.48k stars 5.18k forks source link

Deno stalls out after ~9500 concurrent `fetch()` requests in EasyRacer structured concurrency suite scenario 3 #20326

Open cowboyd opened 10 months ago

cowboyd commented 10 months ago

I'm trying to implement a Deno version of EasyRacer, and all scenarios are passing except for scenario 3 which makes 10,000 concurrent requests. When monitoring the scenario server, it appears that it climbs up to about ~9500 requests before stalling out.

I recognize that this isn't a normal use case; it's designed to test the capabilities of a system rather than be a guide for optimal usage. However, there are successful implementations for Scala, Java, Kotlin, Swift, Rust, and Go.

Here is a link to my implementation: https://github.com/cowboyd/easyracer/tree/main/javascript-effection

josephrocca commented 10 months ago

I recognize that this isn't a normal use case

I have real-world use cases which aren't toooo far off these numbers, so I really appreciate that you're doing this sort of testing :pray:

Note that the link you gave is a 404 - I think it needs to be updated to this: https://github.com/cowboyd/easyracer/tree/main/javascript-effection

cowboyd commented 10 months ago

@josephrocca Thanks for the catch! I've update the link in the issue.

It looks like one of the problems is that there is no way to be notified when every single resource allocated by a request has been released. In other words, you can fire your AbortSignal, but there's no callback that closes the loop telling you that the abort is complete.

This isn't so much a problem with Deno as with the fetch() API itself. I did look into using Deno.createHttpClient(), but that didn't seem to help either.

And great to know that this work at the edges isn't purely theoretical.

cowboyd commented 8 months ago

Just tested this against Deno 1.38, and still get the same result.