Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Clean up HTTP async iterator code #411
2 times, most recently
May 16, 2019
That's no longer possible, because no new requests will be accepted on the same connection before the previous one has done responding.
Is this PR may fix the issue of malformed or encrypted mime headers?
Returning an error 400 if the request can't be properly read.
Not atm because we use
But i can write some like done in : https://github.com/denoland/deno_std/blob/master/http/racing_server_test.ts
For ref: denoland/deno#2346
This PR results in a 1/3 reduction of req/sec:
Latency also seems exceptionally problematic, effectively x100.
@kevinkassimo Can you try again? I think the latest patch should remove the unfair scheduling that was introduced by the MuxAsyncIterator and restore overall performance.
However I'm still seeing pretty bad max-latency values. Note that it's strictly the maximum latency that is quite bad. The overall distribution (the one you get with
@piscisaureus Seems performing better than master now.
There is another small issue I noticed: it seems under 500 concurrent connections our HTTP server would die silently... Might be unrelated to this PR though:
(Actually on master this would result in a panic on
Not so sure why under this PR this panic does not occur but the server still silently dies)