I question that project's long-term viability. Event loop based languages inherently limit systems to inefficient and unreliable concurrency models.
My platform, which I've received seed funding for, is entirely done in Erlang. This technology decision will better enable me to deliver more hello worlds per nanosecond than Node ever could.
I thought the whole point of HTTP/2 was to transfer as many things as possible in one connection so maybe this bug is less of a concern for these types of connection.
The headline says "20%", which would imply that a "similar slowdown" for a 100 milliseconds response would bring it to 120 milliseconds.
But what is actually happening is that every request takes roughly an extra 0.04 milliseconds, so the time might go up to 100.04 milliseconds, probably within margin of error for most services anyway.
Seems like an easy debunk here is a test that has a more realistic response delay instead so that the slowdown can de demonstrated as an absolute amount vs. a percentage amount.
It's so hard to imagine high traffic application with api serving information to clients from array that is refreshed once in 10 minutes? So basically most of the time you touch only this array on every request which is like sending hello world example. In this situation it will be noticeable if you have a lot of traffic but then you would not use stdlib http library but something like fasthttp which doesn't change that there are other real world use cases that would be affected, not a lot of them but they exist.