Hacker News Reader

Comment by latch | Hacker News Reader

Like many http server implementations in Zig, this is a wrapper around `std.http.Server`. `std.http.Server` only exists as a mechanism to test the `std.http.Client` (which is needed for things like, downloading packages). So `std.http.Server` isn't built to be fast, secure or robust.

I believe you _can_ get keepalive working with `std.http.Server`, but it seems like Tokamak isn't using it that way. The implementation is a thread-per-connection. Those are the two most obvious issues specific to this implementation.

But I believe the bulk of the issues relate to `std.http.Server`. It shouldn't be public/used.

View on HN

Oh, I didn't know std.http.Server is not supposed to be used. I guess I could just use your project (as dependency) and that would fix that perf issue? And do a thread-pool and keep-alive, of course.

TBH perf was not my priority yet, I only wanted predictable memory usage and Zig was perfect choice for that (when compared to node.js).

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/b3aed4e2c8b4d48b8b12f606...

Hm, 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.

Yeah, I'm with you, I thought this thing was just waiting for some "function colouring" behaviors to be ironed out in zig before it was to be polished. I guess comments from https://news.ycombinator.com/item?id=35991684 made me think this but it's good to have been informed that this in fact is not the case (and is closer to a com.sun.net.httpserver.HttpServer as a ref for us ole java folk)

Reply on news.ycombinator.com