# Game traffic benchmarks `game_traffic.py` exercises real RFC 6455 over verified TLS, with a separate Python backend. Pin Python 3.12 and websockets 17.1; install psutil for resource sampling. ```sh cp ./superweb build/superweb-measured uv run --python 3.12 --with websockets==17.1 --with psutil \ python bench/game_traffic.py run --binary build/superweb-measured \ --output build/games.json --seconds 8 --rounds 3 ``` Use an immutable binary copy. Rebuilding a binary during a multi-process local run can mix versions. Local runs share CPU and networking with the backend and client; they are not private-network AWS results. For separate machines, run `backend --port 19090` on the server and configure Superweb with `--workers 2 --proxy /game=127.0.0.1:19090`, a trusted test certificate, and a public directory containing `asset.bin` (`bytes(range(256)) * 4096`). On the client: ```sh python bench/game_traffic.py load --url wss://SERVER:18443/game \ --cafile cert.pem --asset-url https://SERVER:18443/asset.bin \ --output measured.json --seconds 8 --rounds 3 ``` The certificate SAN must match SERVER. Never disable verification to make a run pass. Use the same backend, client, certificate and flags for both binaries. `--cases echo-64,mixed-assets` selects workloads; `--connections 256 --seconds 300 --rounds 1` runs a 256-byte, 20 Hz sustained echo workload. Cases include one and 64 players, 64/256/1024-byte messages at 20 or 60 Hz, 16-player broadcast rooms, 1 MiB HTTPS asset downloads alongside play, idle connections with backend heartbeats, eight paused flood readers among 64 connections, and five 64-connection reconnect waves. All player connections are attempted together with a three-second handshake deadline. Compression is disabled. Latency is send-to-receive on the same client clock; it includes proxy, TLS, network, backend and client scheduling. Open-loop scheduling lag is reported separately. Eight-second slow-reader measurements check isolation; the regression suite separately exercises write timeouts. Every result retains connection failures, payload errors, unanswered messages, asset failures, completed asset counts, verified messages and client CPU. The broadcast target is 20,480 recipient messages/s at 64 players; echo-64 is 3,840/s. Idle tests use protocol ping/pong and do not produce game-message latency samples. Reconnect rows count 320 attempted connections per round. On Linux, `game_monitor.py --server PID --backend PID --output resources.jsonl` samples CPU seconds, RSS, PSS, descriptors, host used memory and network counters every 0.2 seconds. It stops after at most 30 minutes. `summarize_games.py` joins timestamps and preserves every round. Process CPU is measured in cores (1.0 = one full core); PSS apportions shared pages. Host used memory is total minus available, including the OS. Peaks are sampled peaks, not an exact allocation high-water mark. CPU windows include connection setup and teardown. Fewer successful clients can make the baseline appear cheaper or faster; always show failure counts beside latency. `ascii_bench.c` isolates ASCII header comparison. Build it with the platform parser assembly; its speedup is a kernel measurement, not game throughput. Guard-page and all-byte correctness tests live in `test/test_parse.c`. `aws_game_template.json` defines the disposable server, client and nano stack; provide Vpc, Subnet, Ami (Ubuntu 24.04 ARM64) and ArtifactBucket parameters. It creates EC2 instances and an SSM role; keep the benchmark ports private to its security group. `aws_game_ops.py` is scoped to the disposable `superweb-game-benchmark` stack in the beta account. It retains SSM command evidence under `build/game-benchmark`. Keep benchmark resources separate from the five public comparison hosts, archive data before deleting the temporary stack, and do not publish claims beyond the measured load. The October 17 report is in `benchmarks/2026-10-17-games.md`.