4 ms·
The biggest issue with std.http.Server is [1]: This server assumes *all* clients are well behaved and standard compliant; it can and will deadlock if a clie
by latch 3y ago
The biggest issue with std.http.Server is [1]:
This server assumes *all* clients are well behaved and standard compliant; it can and will deadlock if a client holds a connection open without sending a request.
Atop your readme, you point out that nginx or another reverse proxy should be used. Kudos for that.
As for performance, I'd be curious what gains you get using `std.http.Server` with keepalive and a threadpool. Possibly you can re-use your ThreadContext - having 1 per thread in the threadpool that you can re-using. `std.Thread.Pool` is also very poorly tuned for a large number of small batch jobs, but that's a place to start.
[1] https://github.com/ziglang/zig/blob/b3aed4e2c8b4d48b8b12f606f56e5aae7ec4693b/lib/std/http/Server.zig#L3 https://github.com/ziglang/zig/blob/b3aed4e2c8b4d48b8b12f606...
- cztomsik 3y agoHm, thanks for pointing that out. I need nginx for SSL anyway, so I was not even thinking about going raw :) I'm wondering where exactly is the problem in the std.http.Server because it might be easy to fix. Maybe it's just that nobody cared yet... But 2x slower than Ruby sounds awful. > Possibly you can re-use your ThreadContext Yes, this is the idea, and extending the injector for request-scoped and thread-scoped dependencies.