update to new zig async io

[philipmv]

https://github.com/philipmv/zzz.io

if you find it useful i'll create pull request

[bernardassan]

I don't speak on behalf of @mookums, but Zig's async Io is very exciting and very brittle now, Io.Threaded is been reimplemented.

I think it is safe to play around with it, but to wait till 0.16.0 to start adopting it in zzz

The comptime template engine you added looks interesting

[philipmv]

I created it as an experiment, but because it works well, I decided to publish it. It is very easy to switch an existing zzz app to zzz.io and see how it behaves, make benchmarks, etc. I know it is a very early stage of the Zig async implementation, but it really works. Even if there are ongoing improvements in the Io.Threaded implementation, I think the Io interface is stable, so it is okay to use it and try how zzz works with the latest Zig versions.

The comptime template is very simple, but I think it greatly simplifies HTML generation without sacrificing speed.

[bernardassan]

I haven't seen any benchmarks of the new Async Io implementation. I'm curious to see how zzz.io examples perform compared to zzz

[philipmv]

This is basic example compiled ReleaseFast on FreeBSD 14.3. It will be interesting and more fare to compare it against Io.Evented when it is ready.

zzz.io

wrk -c 100 -t 2 -d 5 --latency "http://127.0.0.1:9862/"

Running 5s test @ http://127.0.0.1:9862/
  2 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    49.00us    8.30us 682.00us   86.18%
    Req/Sec    92.77k     6.75k  103.80k    76.47%
  Latency Distribution
     50%   48.00us
     75%   52.00us
     90%   57.00us
     99%   74.00us
  469988 requests in 5.10s, 51.10MB read
Requests/sec:  92139.86
Transfer/sec:     10.02MB

wrk -c 100 -t 10 -d 5 --latency "http://127.0.0.1:9862/"

Running 5s test @ http://127.0.0.1:9862/
  10 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    50.21us    9.72us   1.20ms   86.23%
    Req/Sec    89.69k     8.10k  102.16k    74.51%
  Latency Distribution
     50%   49.00us
     75%   53.00us
     90%   59.00us
     99%   84.00us
  454273 requests in 5.10s, 49.39MB read
Requests/sec:  89149.21
Transfer/sec:      9.69MB

zzz

wrk -c 100 -t 2 -d 5 --latency "http://127.0.0.1:9862/"

Running 5s test @ http://127.0.0.1:9862/
  2 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.13ms    4.40ms  73.93ms   98.72%
    Req/Sec    60.42k     9.37k  106.76k    81.19%
  Latency Distribution
     50%  748.00us
     75%    0.88ms
     90%    0.97ms
     99%   14.92ms
  608245 requests in 5.12s, 66.13MB read
Requests/sec: 118685.54
Transfer/sec:     12.90MB

wrk -c 100 -t 10 -d 5 --latency "http://127.0.0.1:9862/"

Running 5s test @ http://127.0.0.1:9862/
  10 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     0.97ms  217.14us  10.88ms   96.54%
    Req/Sec    10.34k   617.91    12.45k    67.25%
  Latency Distribution
     50%    0.95ms
     75%    1.01ms
     90%    1.06ms
     99%    1.32ms
  524861 requests in 5.10s, 57.06MB read
Requests/sec: 102908.25
Transfer/sec:     11.19MB

This is interpretation of results given of Grok:

• Throughput Winner: Benchmark 2, with ~29% higher requests/sec and data transfer. It completed more work in nearly the same time.
• Latency Winner: Benchmark 1, with sub-millisecond responses across percentiles and far lower tail latency (e.g., p99 is 200x faster).
• Variability: Benchmark 2 shows much higher latency variance (stdev and max), indicating potential instability under concurrent load. Benchmark 1 is more predictable.
• Trade-offs: If your workload values consistency and low response times (e.g., real-time APIs), prefer Benchmark 1. For high-volume scenarios (e.g., batch processing), Benchmark 2 scales better.

[philipmv]

This is the same benchmark on Linux Fedora 42 with https://github.com/hatoo/oha

zzz.io

oha -n 1000000 -c 2 http://127.0.0.1:9862

Summary:
  Success rate:	100.00%
  Total:	7308.1972 ms
  Slowest:	9.3481 ms
  Fastest:	0.0099 ms
  Average:	0.0141 ms
  Requests/sec:	136832.6522

  Total data:	12.40 MiB
  Size/request:	13 B
  Size/sec:	1.70 MiB

Response time histogram:
  0.010 ms [1]      |
  0.944 ms [999976] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  1.878 ms [7]      |
  2.811 ms [0]      |
  3.745 ms [0]      |
  4.679 ms [0]      |
  5.613 ms [0]      |
  6.547 ms [0]      |
  7.480 ms [4]      |
  8.414 ms [2]      |
  9.348 ms [10]     |

Response time distribution:
  10.00% in 0.0114 ms
  25.00% in 0.0115 ms
  50.00% in 0.0122 ms
  75.00% in 0.0144 ms
  90.00% in 0.0177 ms
  95.00% in 0.0232 ms
  99.00% in 0.0294 ms
  99.90% in 0.1273 ms
  99.99% in 0.2225 ms


Details (average, fastest, slowest):
  DNS+dialup:	0.2481 ms, 0.1945 ms, 0.3017 ms
  DNS-lookup:	0.0170 ms, 0.0121 ms, 0.0220 ms

Status code distribution:
  [200] 1000000 responses

zzz

oha -n 1000000 -c 2 http://127.0.0.1:9862

Summary:
  Success rate:	100.00%
  Total:	6987.2504 ms
  Slowest:	10.3823 ms
  Fastest:	0.0106 ms
  Average:	0.0135 ms
  Requests/sec:	143117.8145

  Total data:	12.40 MiB
  Size/request:	13 B
  Size/sec:	1.77 MiB

Response time histogram:
   0.011 ms [1]      |
   1.048 ms [999997] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
   2.085 ms [0]      |
   3.122 ms [0]      |
   4.159 ms [0]      |
   5.196 ms [0]      |
   6.234 ms [0]      |
   7.271 ms [0]      |
   8.308 ms [0]      |
   9.345 ms [0]      |
  10.382 ms [2]      |

Response time distribution:
  10.00% in 0.0115 ms
  25.00% in 0.0119 ms
  50.00% in 0.0125 ms
  75.00% in 0.0132 ms
  90.00% in 0.0155 ms
  95.00% in 0.0184 ms
  99.00% in 0.0274 ms
  99.90% in 0.1232 ms
  99.99% in 0.2128 ms


Details (average, fastest, slowest):
  DNS+dialup:	0.2178 ms, 0.1830 ms, 0.2526 ms
  DNS-lookup:	0.0159 ms, 0.0147 ms, 0.0171 ms

Status code distribution:
  [200] 1000000 responses

[philipmv]

On Fedora 43

zzz.io

oha -n 1000000 -c 10 http://127.0.0.1:9862

Summary:
  Success rate:	100.00%
  Total:	3210.1258 ms
  Slowest:	3.8480 ms
  Fastest:	0.0118 ms
  Average:	0.0303 ms
  Requests/sec:	311514.2747

  Total data:	12.40 MiB
  Size/request:	13 B
  Size/sec:	3.86 MiB

Response time histogram:
  0.012 ms [1]      |
  0.395 ms [999938] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  0.779 ms [20]     |
  1.163 ms [9]      |
  1.546 ms [28]     |
  1.930 ms [0]      |
  2.314 ms [2]      |
  2.697 ms [1]      |
  3.081 ms [0]      |
  3.464 ms [0]      |
  3.848 ms [1]      |

Response time distribution:
  10.00% in 0.0194 ms
  25.00% in 0.0229 ms
  50.00% in 0.0277 ms
  75.00% in 0.0341 ms
  90.00% in 0.0421 ms
  95.00% in 0.0493 ms
  99.00% in 0.0790 ms
  99.90% in 0.1748 ms
  99.99% in 0.2862 ms


Details (average, fastest, slowest):
  DNS+dialup:	0.3066 ms, 0.1781 ms, 0.4969 ms
  DNS-lookup:	0.0289 ms, 0.0011 ms, 0.0740 ms

Status code distribution:
  [200] 1000000 responses

zzz

oha -n 1000000 -c 10 http://127.0.0.1:9862

Summary:
  Success rate:	100.00%
  Total:	3448.7152 ms
  Slowest:	2.3885 ms
  Fastest:	0.0115 ms
  Average:	0.0326 ms
  Requests/sec:	289963.0557

  Total data:	12.40 MiB
  Size/request:	13 B
  Size/sec:	3.59 MiB

Response time histogram:
  0.011 ms [1]      |
  0.249 ms [999890] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  0.487 ms [61]     |
  0.725 ms [16]     |
  0.962 ms [3]      |
  1.200 ms [18]     |
  1.438 ms [7]      |
  1.675 ms [0]      |
  1.913 ms [0]      |
  2.151 ms [0]      |
  2.388 ms [4]      |

Response time distribution:
  10.00% in 0.0207 ms
  25.00% in 0.0246 ms
  50.00% in 0.0301 ms
  75.00% in 0.0370 ms
  90.00% in 0.0451 ms
  95.00% in 0.0523 ms
  99.00% in 0.0829 ms
  99.90% in 0.1773 ms
  99.99% in 0.2516 ms


Details (average, fastest, slowest):
  DNS+dialup:	0.3885 ms, 0.2557 ms, 0.5585 ms
  DNS-lookup:	0.0100 ms, 0.0006 ms, 0.0195 ms

Status code distribution:
  [200] 1000000 responses

[bernardassan]

The benchmark results look promising, and I think it might get better with Io.Evented when it's ready, which more closely matches tardy. @mookums, what do you think?

I think at the very least we would have to consider updating tardy's API to use something like Io.Threaded when a particular evented async operation isn't supported on the Os platform

[philipmv]

On a high load i.e. wrk -t12 -c400 -d10s ... zzz.io starts to degrade. readv in fn netReadPosix in Threaded.zig begins to return CONNRESET. This is both on FreeBSD and Linux.

[philipmv]

I'm interested to see Io.Evented kqueue implementation because I think there is some inefficiency in tardy's implementation because it uses EV_ONESHOT and has to rearm the event on each call to an io operation.