superweb

HTTP PROXY / OCTOBER 17, 2026

Slow APIs and game traffic.

One Superweb worker on an isolated AWS c7g.large (2 vCPUs, 4 GiB), Ubuntu 24.04 ARM64. The HTTP backend, WebSocket backend and client run on the same host over loopback. Each round starts an API request whose backend sleeps for 800 ms. Once the backend confirms receipt, a verified WebSocket echo and a verified static GET run concurrently. The API response must also succeed. Five rounds per build; the old build runs first. Values are medians, with every sample retained. This is a worker-interference regression, not a randomized throughput or maximum-capacity benchmark. It includes client/backend scheduling and local transport overhead. It does not measure AWS network bandwidth, t4g.nano burst behavior, or performance against other web servers. CPU and RAM were not sampled in this check.

BuildWebSocket echo · medianStatic GET · medianErrors · all rounds
Previous HTTP proxy801.36 ms801.10 ms0
Streaming HTTP proxy0.36 ms0.31 ms0

What changed

HTTP/1.1 proxy connections, uploads and responses now progress through the event loop. Application queues grow from 4 KiB to 16 KiB per direction by default; TLS/kernel buffers and bounded header/parsing buffers are additional. Slow peers apply backpressure to their own connection. Connect, idle and total-request deadlines bound waiting. Client keep-alive and pipelining are retained. A backend still takes its original time to process an API request; other connections no longer inherit that wait.

Validation

Normal and ASan/UBSan server suites passed on macOS ARM64 and Linux ARM64. The HTTP proxy tests also passed on Intel macOS with TLS cases skipped. Eight integration tests cover slow APIs beside game sockets and static files, uploads before completion, incremental responses, keep-alive, HTTP framing, malformed upstreams, early rejection, deadlines, cancellation and shutdown. A 16 MiB TLS response is verified while using 4 KiB proxy queues; paused readers and upstream upload backpressure leave other traffic responsive.

Scope of the measured release

The measured release accepts HTTP/1.1 clients (including TLS) and cleartext HTTP upstreams. That release did not support HTTP/2 proxying, upstream HTTPS or chunked uploads. Current builds add HTTP/2 client proxying. Content-Length uploads retain the 1 MiB limit. Responses stream without a total-size cap. Backend addresses resolve at startup and each request opens a new upstream connection. Configure the total request deadline for long-lived streams. The earlier WebSocket-load and four-server static benchmarks retain their original binaries and numbers; they have not been rerun for this update.

Measured builds

Both Linux ARM64 binaries use -O3 -flto -mcpu=neoverse-n1. Previous release: d3cd598.

Previous HTTP proxy SHA-256:
58fce16b5d6c28a95390ea883cdc79ae846ebc79885c078641c6519f7e54f121

Streaming HTTP proxy SHA-256:
46f890d74bf5c5895ce127fb9292d021b0d1401342d1919964f9a8858b21e715

Every sample and environment · Benchmark harness · HTTP fixture and tests · WebSocket fixture · Reproduction · Checksums