cezarc1/websocket-stt-bench — explained in plain English
Analysis updated 2026-05-18
Compare which language and runtime handles the most concurrent WebSocket audio sessions per CPU.
Use the benchmark harness as a template to test your own streaming service under a similar load.
Read the per-language BENCHMARK.md files to learn tuning tricks for each runtime's WebSocket stack.
| cezarc1/websocket-stt-bench | abc3dz/mixxx | abyo-software/ferro-stash | |
|---|---|---|---|
| Stars | 1 | 1 | 1 |
| Language | Rust | Rust | Rust |
| Setup difficulty | hard | moderate | moderate |
| Complexity | 4/5 | 2/5 | 4/5 |
| Audience | developer | general | ops devops |
Figures from each repo's GitHub metadata at analysis time.
Requires a Kubernetes cluster (k3s) and building multiple language runtimes to reproduce the full benchmark.
websocket-stt-bench is a benchmark project that measures how many concurrent WebSocket audio streaming sessions different programming languages and runtimes can handle on a single virtual CPU. It simulates a speech to text gateway: clients stream small chunks of raw audio over a WebSocket connection, and each server implementation buffers that audio, periodically sends it to a shared Rust based inference simulator, and returns partial transcript results back to the client as JSON messages. The project builds the same benchmark server in many different languages and frameworks so they can be compared side by side, including C++ with uWebSockets, Python with FastAPI and uvloop, Elixir with Phoenix, Rust with both async Axum and a lower level two thread version without an async runtime, TypeScript on Bun, Go, Java with Helidon virtual threads, Scala with the Pekko actor framework, and two flavors of OCaml. Each implementation is tested against the same service level target, and results are reported as the highest number of concurrent sessions that still met that target at one and two virtual CPUs. According to the results in the README, a plain Rust build using two threads and no async runtime handled the most sessions per CPU, narrowly ahead of the C++ implementation, while async Rust with Axum offered the best balance between how much code it took to write and how many sessions it could handle. Java, Bun, and Go form a middle tier, and Elixir and Scala score lower on a single CPU but scale up well when given a second one. The author notes using AI coding agents to help write several of the language implementations, with varying levels of ease depending on the language. The benchmarks were run on a single machine with an Intel Core i9 processor, Ubuntu, and a small Kubernetes cluster, and detailed run notes for each language live in their own benchmark documents inside the repository. The project is written primarily in Rust.
A benchmark comparing how many concurrent WebSocket audio streaming sessions different languages and runtimes handle per CPU.
Mainly Rust. The stack also includes Rust, C++, Python.
Setup difficulty is rated hard, with roughly 1h+ to a first successful run.
Mainly developer.
This repo across BitVibe Labs
Verify against the repo before relying on details.