Benchmarks

See how Ferron compares to other web servers in terms of performance for various use cases.

How to read the benchmarks?

Ferron is designed for predictable, high-performance behavior under real-world web workloads, including TLS, HTTP/2, connection reuse, and high concurrency, rather than for winning isolated microbenchmarks.

Ferron also prioritizes correctness, scalability, and modern protocol support under extreme concurrency. While it may not always lead in peak static file serving throughput, it demonstrates stable performance, and strong behavior under load.

The results below are grouped according to common deployment scenarios to help you evaluate performance in contexts that may match how you would actually run Ferron.

Note: The static file serving benchmarks focus on medium and large static files under HTTP/2, highlighting sustained throughput and backpressure behavior rather than small-file protocol overhead.

Reverse proxying

Reverse proxy performance

Requests per second when proxying to a "Hello World" Axum application (higher is better)

Higher is better | Benchmarks run on AMD Ryzen 7 8700G, 32GB RAM, with the h2load -n $(($CONCURRENCY * 100)) -c $CONCURRENCY -t 16 https://localhost command | Linux kernel version 6.14.0-27-generic | Benchmarks performed on January 5, 2026

Note: During the NGINX benchmark runs h2load logged "Process Request Failures".

Latency under load (reverse proxy)

Mean response time under high concurrency proxying to a "Hello World" Axum application (lower is better)

Lower is better | Benchmarks run on AMD Ryzen 7 8700G, 32GB RAM, with the h2load -n $(($CONCURRENCY * 100)) -c $CONCURRENCY -t 16 https://localhost command | Linux kernel version 6.14.0-27-generic | Benchmarks performed on January 5, 2026

Note: During the NGINX benchmark runs h2load logged "Process Request Failures".

Static file serving

Requests per second when serving static files (higher is better)

Higher is better | Benchmarks run on AMD Ryzen 7 8700G, 32GB RAM, with the h2load --duration 10s -c 100 -t 16 -m 8 https://localhost command | Linux kernel version 6.14.0-27-generic | Benchmarks performed on January 5, 2026

Note: During the Apache and NGINX benchmark runs h2load logged "Process Request Failures". For 100 KiB file and NGINX, 1s duration was used instead.

PHP

PHP performance

Requests per second when serving PHP through PHP-FPM (higher is better)

Higher is better | Benchmarks run on AMD Ryzen 5 8600G, 32GB RAM, with the ferrbench -c 100 -d 60s -t 12 -h https://localhost --http2 command | Benchmarks performed on June 13, 2025

Interpreting small differences

In practice, differences on the order of 10–20% in synthetic throughput or latency benchmarks often translate to little or no perceptible difference for end users:

Browsers are limited by network latency and TLS handshakes.
HTTP/2 and HTTP/3 multiplex requests over shared connections.
Static assets are typically cached at the server, CDN, or browser level.

For most real-world deployments, stability under load, worst-case response times (for example, 99th percentile response time), and operational simplicity have a greater impact than small throughput differences measured in isolation.