mirror of
https://github.com/zigzap/zap.git
synced 2025-10-20 15:14:08 +00:00

In the 0.12.0 branch, [httpz](https://github.com/karlseguin/http.zig) was added to the perf measurements. Apparently, somehow this got lost, which is a pity. httpz is super-promising. Given the perf benchmarks in [this PR comment](https://github.com/antonputra/tutorials/pull/280#issuecomment-2362637299), I would have expected httpz to be on par with or better than zap in our `measure.sh` tests. However, on my M3 max mac box, I get the following: **ZAP**: ``` ➜ zap git:(reintroduce_httpz_perf) ✗ ./wrk/measure.sh zig-zap INFO: Listening on port 3000 Listening on 0.0.0.0:3000 INFO: Server is running 4 workers X 4 threads with facil.io 0.7.4 (kqueue) * Detected capacity: 131056 open file limit * Root pid: 73099 * Press ^C to stop INFO: 73110 is running. INFO: 73111 is running. INFO: 73112 is running. INFO: 73113 is running. ======================================================================== zig-zap ======================================================================== Running 10s test @ http://127.0.0.1:3000 4 threads and 400 connections Thread Stats Avg Stdev Max +/- Stdev Latency 1.31ms 533.41us 18.77ms 90.57% Req/Sec 76.67k 9.04k 86.46k 84.25% Latency Distribution 50% 1.15ms 75% 1.17ms 90% 1.75ms 99% 2.94ms 3052064 requests in 10.02s, 462.80MB read Socket errors: connect 0, read 135, write 0, timeout 0 Requests/sec: 304601.19 Transfer/sec: 46.19MB ``` **httpz**: ``` ➜ zap git:(reintroduce_httpz_perf) ✗ ./wrk/measure.sh httpz ======================================================================== httpz ======================================================================== Running 10s test @ http://127.0.0.1:3000 4 threads and 400 connections Thread Stats Avg Stdev Max +/- Stdev Latency 2.26ms 528.72us 18.84ms 84.61% Req/Sec 44.46k 7.35k 85.50k 88.00% Latency Distribution 50% 2.35ms 75% 2.39ms 90% 2.43ms 99% 3.26ms 1768925 requests in 10.01s, 91.10MB read Socket errors: connect 0, read 230, write 0, timeout 0 Requests/sec: 176712.50 Transfer/sec: 9.10MB ``` Which looks way off. I must admit, I might have done a bad httpz implementation. Seeking help from @karlseguin. My motivation: route people away from zap to alternatives like httpz or even zzz, as those are pure zig, and seem to be of really good performance. I want a world in which we don't have to resort to C frameworks to do good, zig-worthy servers 😄 to come true.
60 lines
2.6 KiB
Zig
60 lines
2.6 KiB
Zig
const std = @import("std");
|
|
|
|
// Although this function looks imperative, note that its job is to
|
|
// declaratively construct a build graph that will be executed by an external
|
|
// runner.
|
|
pub fn build(b: *std.Build) void {
|
|
// Standard target options allows the person running `zig build` to choose
|
|
// what target to build for. Here we do not override the defaults, which
|
|
// means any target is allowed, and the default is native. Other options
|
|
// for restricting supported target set are available.
|
|
const target = b.standardTargetOptions(.{});
|
|
|
|
// Standard optimization options allow the person running `zig build` to select
|
|
// between Debug, ReleaseSafe, ReleaseFast, and ReleaseSmall. Here we do not
|
|
// set a preferred release mode, allowing the user to decide how to optimize.
|
|
const optimize = b.standardOptimizeOption(.{});
|
|
|
|
const exe = b.addExecutable(.{
|
|
.name = "httpz",
|
|
.root_source_file = b.path("main.zig"),
|
|
.target = target,
|
|
.optimize = optimize,
|
|
});
|
|
|
|
const httpz = b.dependency("httpz", .{
|
|
.target = target,
|
|
.optimize = optimize,
|
|
});
|
|
|
|
// the executable from your call to b.addExecutable(...)
|
|
exe.root_module.addImport("httpz", httpz.module("httpz"));
|
|
|
|
// This declares intent for the executable to be installed into the
|
|
// standard location when the user invokes the "install" step (the default
|
|
// step when running `zig build`).
|
|
b.installArtifact(exe);
|
|
|
|
// This *creates* a Run step in the build graph, to be executed when another
|
|
// step is evaluated that depends on it. The next line below will establish
|
|
// such a dependency.
|
|
const run_cmd = b.addRunArtifact(exe);
|
|
|
|
// By making the run step depend on the install step, it will be run from the
|
|
// installation directory rather than directly from within the cache directory.
|
|
// This is not necessary, however, if the application depends on other installed
|
|
// files, this ensures they will be present and in the expected location.
|
|
run_cmd.step.dependOn(b.getInstallStep());
|
|
|
|
// This allows the user to pass arguments to the application in the build
|
|
// command itself, like this: `zig build run -- arg1 arg2 etc`
|
|
if (b.args) |args| {
|
|
run_cmd.addArgs(args);
|
|
}
|
|
|
|
// This creates a build step. It will be visible in the `zig build --help` menu,
|
|
// and can be selected like this: `zig build run`
|
|
// This will evaluate the `run` step rather than the default, which is "install".
|
|
const run_step = b.step("run", "Run the app");
|
|
run_step.dependOn(&run_cmd.step);
|
|
}
|