Behind the
benchmarks.

Use performance alongside language preference, team experience, maintainability, documentation and support. Validate the shortlist against your application workload and hardware.

They expose different abstraction costs. Filter by classification, database, ORM and platform when you need comparable stacks; the unfiltered table is deliberately broad.

Realistic targets a general-purpose production configuration. Stripped is specially configured or built for benchmark requirements and can be unsuitable as a production starting point. Stripped is hidden initially, as in the original viewer.

The implementation did not complete the workload successfully or pass the required validation. A failed test is shown as a failure, rather than assigned a performance score. Follow its logs to investigate.

Workload support and included implementations change between rounds. A configuration in the current repository does not imply that it was measured in a historical publication.

Hardware, network, software versions and implementations change over time. Treat each round and environment as a separate experiment. This portal does not combine them into a single score.

Published throughput uses the round duration and completed request counts after connection, read, write and HTTP 5xx errors. Latency comes from the same selected sample. For query workloads, select the query count; for concurrency workloads, inspect all levels as well as the best sample.

The local results tool divides totalRequests by measured elapsed timestamps. The published-round viewer uses the published duration and error-adjusted counts. These are different calculations, so their values can differ.

It compares an implementation with its explicitly declared platform baseline in the same test and environment. The percentage here is framework RPS divided by baseline RPS. No baseline is inferred from a similar name or language.

The upstream procedure describes a 5-second primer at concurrency 8, a 15-second warmup at 256 and measured samples at the workload levels. Primer and warmup are excluded from published measurements. Check runner settings when reproducing a run.

The suite balances measurement time against a large number of implementations. A short synthetic run cannot represent every long-lived application, GC pattern or JIT behavior. Extend duration and repeat runs for your own investigation.

wrk is the multithreaded HTTP load generator. It issues requests for a configured duration and records request counts, latency and errors. Load-generator or network saturation can limit the observed application throughput.

Cached queries is a separate workload with its own requirements. Ordinary database tests must perform their specified database operations. Responses served without executing application work by an external reverse cache would change what is being measured.

The upstream expectations include connection pooling and configurations that use the available CPU resources. Application logging is generally disabled in the benchmark. Review each implementation rather than assuming all production defaults are enabled.

The suite evolves through community contributions. Report configuration problems with a reproducible example or submit a change with verification results. A published round remains a historical snapshot even after the repository is updated.

Start from the workload requirements, contribute an implementation and verify it with the runner. Use the fork for Better Web changes and the upstream project for changes intended for official TechEmpower rounds.

TFB Status publishes continuous benchmark runs and logs. These are useful for diagnosing contributions and are distinct from official published rounds.

The original viewer starts its historical data at round 3 because early result formats and identifiers changed. The first two releases remain available as TechEmpower blog posts below.