4 ms·

As a Zig developer with one of the more popular HTTP server libraries around (http.zig), this is impressive and good use of comptime and (good) abuse of Zig's a

by latch 3y ago

As a Zig developer with one of the more popular HTTP server libraries around (http.zig), this is impressive and good use of comptime and (good) abuse of Zig's anytype. I'm looking forward to learning from the codebase. But, it's very slow. A quick test shows Sinatra is about 2x faster. Maybe I'm in the minority, but I feel that a primary reason to give up a GC is for performance.

nine_k 3y ago
This is really weird; it's not even obvious how to spend so much time in this code. By any chance, have you tried profiling? Just really curious.
- latch 3y ago
  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.
  - cztomsik 3y ago
    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).
    - 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 ago
        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.
    - bjconlan 3y ago
      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 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)
Alifatisk 3y ago
> A quick test shows Sinatra is about 2x faster. There must be something very wrong

by latch 3y ago

nine_k 3y ago

This is really weird; it's not even obvious how to spend so much time in this code. By any chance, have you tried profiling? Just really curious.

latch 3y ago
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.
- cztomsik 3y ago
  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).
  - 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 ago
      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.
  - bjconlan 3y ago
    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 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)

Alifatisk 3y ago

> A quick test shows Sinatra is about 2x faster. There must be something very wrong