Performance

Arka against nginx, Apache and Caddy: the same machine, the same files, the same certificate, measured minutes apart in alternating rounds — and each server set up the way an administrator who cares about speed would set it up. Where Arka is faster this page says so, and where it is slower, too.

In short#

• Static files: Arka was as fast as nginx with 27–42% less CPU, compressed files included; Apache and Caddy were 3 to 7 times slower on small files.
• Reverse proxy over HTTPS: Arka was 3–10% faster than nginx, with up to 26% less CPU, and 2.2 to 8 times as fast as Apache and Caddy. Without HTTPS, nginx was 5% faster.
• PHP: against nginx with kept connections to php-fpm, the same speed with 9% less CPU, and on pages compressed for browsers 15% faster with 62% less CPU. nginx's slowest answers took over half a second, and 101 of its requests timed out after 2 seconds; Arka's slowest took 12–32 ms, and none failed. (Arka 0.1.11 still needed 23% more CPU than this nginx on small scripts.) Against Apache and Caddy, Arka was 9% to 3.9 times as fast with 62–89% less CPU.
• As Ubuntu ships them, nginx and Caddy compress every response again and Arka's leads are much larger — up to 157 times on a compressed script. Those are differences of setup more than of speed, and the main comparison removes them; they are shown separately.

What a visitor notices#

A page's load time is mostly the distance between the visitor and the server — typically 20 to 100 milliseconds — plus whatever the application (PHP, Django…) spends on it. The web server's own share is a fraction of a millisecond with any of these servers, so on a quiet server visitors rarely feel a difference.

Time for one visitor to get a file, one request after another, over HTTPS on the same machine (no network distance; medians):

• Small files come back in a few hundredths of a millisecond from any of them; nobody can notice the difference.
• The 285 KB script, compressed ahead of time, comes back from Arka, nginx and Caddy in 0.14–0.21 ms. Apache compressed it again for every visitor and took 18 ms — as nginx (16.5 ms) and Caddy (5 ms) do when nobody has made those copies.
• The PHP page takes all four between 1.5 and 2.2 ms, almost all of it PHP's own work. Arka was the quickest: zstd, which it uses for pages made per request, is quicker to make than nginx's brotli or Apache's gzip, and smaller. Caddy sends zstd too, and took 1.78 ms.

What each server sends when a browser asks for compressed files (Accept-Encoding: gzip, deflate, br, zstd, as Chrome and Firefox send):

The static files were compressed ahead of time (brotli at its highest level, also gzip and zstd), and Arka, nginx and Caddy all sent those copies; Apache, which needs rewrite rules for that, compressed them itself. Without such copies Arka compresses a file once with brotli and keeps it (0.2 KB and 77.4 KB here). For pages made per request — the PHP page — Arka uses zstd, as small as brotli and quicker to make (Safari, which has no zstd, gets brotli).

CPU per request, at a glance#

When a server is busy, what limits it is CPU: the less CPU each request costs, the more visitors one machine can serve before it slows down, and the more CPU is left for the applications running beside it. The table shows how much CPU Arka spent per request compared with each server — less means Arka could serve more on the same hardware.

Against nginx#

nginx/1.24.0 (Ubuntu) — the most widely used web server — at its best: files compressed ahead of time served by gzip_static and brotli_static (the brotli module from Ubuntu's packages), brotli at level 4 for pages made per request, sendfile, open_file_cache, HTTP/2, kept connections to the application, and kept connections to php-fpm (fastcgi_keep_conn, 8 per worker: php-fpm's 32 workers in all).

• Static files: the same speed — the load generator, not the servers, set the pace — with Arka using 32% less CPU for a small page, 27% less for the same page compressed, 42% less for the compressed script and 37% less for a 1 MB file (its slowest 1% of answers: 25 ms against 31 ms). Both sent the same copies compressed ahead of time.
• New HTTPS connection for every request: nginx got about 5% more requests through, but here the load generator ran out of CPU first — Arka used 1.2 of its 4 cores, nginx 2.3. Arka needed 43% less CPU per connection, which is what counts when many new visitors arrive at once.
• Proxy over HTTPS: 3% faster on small answers with 10% less CPU, 10% faster on 30 KB pages with 26% less. Over HTTP/2 Arka was 10% faster with about the same CPU per request.
• Proxy without HTTPS: nginx was 5% faster, with 8% less CPU. This only matters when something in front of the server (a CDN or load balancer) handles HTTPS.
• PHP: with connections to php-fpm kept open, nginx served as many requests a second as Arka of a tiny script and of a full page, with about 10% more CPU per request — but its slowest 1% of answers took 525 and 825 ms, against Arka's 12 and 31 ms, and 101 requests timed out after 2 seconds (the tables count them). php-fpm gives each open connection a worker of its own, so a connection an nginx worker keeps idle holds a php-fpm worker that a request in another nginx worker is waiting for. nginx's max_conns refuses requests over the limit rather than queueing them (a queue comes with the commercial nginx Plus); Arka keeps at most max_conns connections, queues the rest, and serves them in the order they came. Fewer kept connections per nginx worker would mean fewer stalls and less speed; this used the usual figure, one per php-fpm worker in all. On the page compressed for browsers, Arka was 15% faster with 62% less CPU — zstd against nginx's brotli at level 4.

Against Apache#

Apache/2.4.58 (Ubuntu) with the event MPM (4 processes × 64 threads, started up front), sendfile, mod_deflate at level 6, mod_http2, mod_proxy and PHP through proxy_fcgi — the way Ubuntu sets up php-fpm for Apache.

• Arka was faster in every test, and used less CPU in every test — usually by a wide margin: 3.4 times as many small pages, 6.9 times as many compressed ones, 2.2 to 5.2 times as many proxied requests, with about a third of Apache's CPU per request or less.
• The compressed script: Apache was not given copies compressed ahead of time (it needs rewrite rules for them) and compressed it for every visitor — that, not Apache's speed, is the 178 times. nginx and Caddy do the same without such copies.
• Large files: Arka 42% faster with 60% less CPU, and far steadier — its slowest 1% of answers took 25 ms, Apache's 236 ms.
• New HTTPS connection for every request: Arka 6% faster, with 66% less CPU per connection.
• PHP: Arka 2.5 times as fast on a tiny script with 83% less CPU; 9% faster on a full page (PHP is the limit) with 62% less; 25% faster on a compressed page with 74% less. On the tiny script Apache's slowest 1% of answers came a little sooner than Arka's (11 ms against 12 ms); on full pages Arka's did.

Against Caddy#

Caddy v2.11.7, the current release from Caddy's own downloads, with file_server serving files compressed ahead of time (precompressed br zstd gzip), encode zstd gzip for everything else, reverse_proxy and php_fastcgi.

• Arka was faster in every test but one: 3.1 to 3.8 times as many static pages, 2.6 to 8.2 times as many proxied requests, and 38–90% less CPU per request in every test.
• The compressed script: with copies compressed ahead of time, Caddy closed most of the gap — Arka 45% faster with 69% less CPU, against 36 times as fast when Ubuntu's Caddy compressed it for every visitor.
• New HTTPS connection for every request: Caddy got about 11% more requests through, with the load generator again the limit — Arka used 1.2 cores, Caddy 2.5; Arka needed 46% less CPU per connection.
• Large files: 7% faster with 38% less CPU, and a slowest 1% of 24 ms against Caddy's 214 ms.
• PHP: Arka 3.9 times as fast on a tiny script with 89% less CPU, and 18% faster on a full page and on a compressed one, with 77% and 65% less; both sent that page as zstd, at the same 2.6 KB. Arka's slowest answers came sooner in all three.
• Its version: the current Caddy was no faster here than Ubuntu's 2.6.2 from 2022 — slightly slower on the proxy tests.

Where Arka is behind#

Plain-HTTP proxying. Without HTTPS, nginx's proxy was 5% faster than Arka's and used 8% less CPU per request. Over HTTPS — how websites are actually served — Arka is ahead, because its encryption costs less.

The slowest PHP answers under full load. With every php-fpm worker busy, Arka's slowest 1% of answers were not always the quickest: on a script that only prints a line, 12 ms against 10 ms for nginx as Ubuntu sets it up and 11 ms for Apache; on a full page, 31 ms against 30 ms for that nginx; on a compressed page, 32 ms against 27 ms for nginx with kept connections — although Arka served as many requests a second or more each time (30% more than that nginx, and two and a half times Apache's, on the tiny script). On the other PHP tests, nginx with kept connections stalled for half a second and more.

As Ubuntu ships them#

Most servers run with their package's settings. Against nginx and Caddy as Ubuntu 24.04 sets them up — nginx with gzip at level 6 and a new connection to php-fpm for every request, Ubuntu's Caddy 2.6.2 with a plain file_server — the same tests, run the same day, gave Arka much larger leads (Arka's speed, and its CPU per request):

The large leads on compressed files come from those servers compressing every response again, which copies compressed ahead of time avoid, as the main comparison shows. The PHP lead over this nginx comes from Arka keeping its connections to php-fpm open — without the stalls above — and from zstd. Apache's figures in the main comparison are already as Ubuntu sets it up.

How we measured#

What CPU per request means. Requests per second only show who is faster when the server is the bottleneck; on this laptop the load generator often was, so both servers reached similar numbers. CPU per request measures how much work each server did for the same result, which is what decides how many visitors a real server can take.

Limits of this comparison. It is one machine, over loopback (no real network), with a handful of request types at 64 connections — not thousands of connections, slow mobile clients, HTTP/3 or long runs — and it was run by the people who make Arka. Your applications, files and hardware will give different numbers. That is why everything needed to repeat it is here: the configurations below, and the script and every result file (with the load generators' own output).

default = true
server_names = ["bench.local"]
listen = ["127.0.0.1:18892"]
request_id = false                  # nginx adds no request id by default either

[tls]
listen = ["127.0.0.1:18445"]
cert = "/srv/bench/tls/cert.pem"
key = "/srv/bench/tls/key.pem"

[log]
enabled = false                     # access logs off for every server

[compression]
enabled = true
min_size = "512B"

[[routes]]
path = "/proxy/"
handler = { type = "proxy", upstreams = ["127.0.0.1:18893"], strip_prefix = true, forward_headers = false }

[[routes]]
path = "/app/"
handler = { type = "fastcgi", address = "unix:/run/bench/php-a.sock", root = "/srv/bench/www", max_conns = 32, queue = { size = 1000, timeout = "30s" } }

[[routes]]
path = "/"
handler = { type = "static", root = "/srv/bench/www" }

load_module /usr/lib/nginx/modules/ngx_http_brotli_filter_module.so;
load_module /usr/lib/nginx/modules/ngx_http_brotli_static_module.so;
worker_processes 4;
events { worker_connections 8192; use epoll; multi_accept on; }
http {
  include /etc/nginx/mime.types;
  access_log off;
  sendfile on; tcp_nopush on; tcp_nodelay on;
  keepalive_timeout 65; keepalive_requests 1000000;
  open_file_cache max=10000 inactive=60s; open_file_cache_valid 60s;
  open_file_cache_min_uses 1; open_file_cache_errors on;
  gzip_static on; brotli_static on;
  gzip on; gzip_comp_level 5; gzip_min_length 512; gzip_vary on;
  gzip_types text/css application/javascript text/javascript application/json image/svg+xml;
  brotli on; brotli_comp_level 4; brotli_min_length 512;
  brotli_types text/css application/javascript text/javascript application/json image/svg+xml;
  ssl_protocols TLSv1.2 TLSv1.3; ssl_session_cache shared:SSL:10m;
  upstream backend { server 127.0.0.1:18893; keepalive 128; }
  # 4 workers x 8 kept connections = php-fpm's 32 workers
  upstream php { server unix:/run/bench/php-b.sock; keepalive 8; }
  server {
    listen 127.0.0.1:18894 reuseport;
    listen 127.0.0.1:18446 ssl http2 reuseport;
    ssl_certificate /srv/bench/tls/cert.pem; ssl_certificate_key /srv/bench/tls/key.pem;
    root /srv/bench/www;
    location /proxy/ { proxy_pass http://backend/; proxy_http_version 1.1; proxy_set_header Connection ""; }
    location ~ ^/app/.+\.php$ {
      try_files $fastcgi_script_name =404;
      include /etc/nginx/fastcgi_params;
      fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
      fastcgi_pass php;
      fastcgi_keep_conn on;
    }
    location / { try_files $uri =404; }
  }
}

# modules: mpm_event, authz_core, mime, dir, filter, deflate, socache_shmcb,
#          ssl, http2, proxy, proxy_http, proxy_fcgi
ServerLimit 4
StartServers 4
ThreadsPerChild 64
MaxRequestWorkers 256
MinSpareThreads 64
MaxSpareThreads 256
MaxConnectionsPerChild 0
KeepAlive On
MaxKeepAliveRequests 0
KeepAliveTimeout 65
EnableSendfile On
Protocols h2 http/1.1
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLSessionCache shmcb:/run/bench/ssl_scache(512000)
AddOutputFilterByType DEFLATE text/html text/plain text/css application/javascript text/javascript application/json image/svg+xml
DeflateCompressionLevel 6
Listen 127.0.0.1:18894
Listen 127.0.0.1:18446 https
DocumentRoot "/srv/bench/www"
<Directory "/srv/bench/www">
  Require all granted
  AllowOverride None
</Directory>
ProxyPass /proxy/ http://127.0.0.1:18893/
ProxyPassReverse /proxy/ http://127.0.0.1:18893/
<FilesMatch "\.php$">
  SetHandler "proxy:unix:/run/bench/php-b.sock|fcgi://localhost"
</FilesMatch>
<VirtualHost 127.0.0.1:18446>
  SSLEngine on
  SSLCertificateFile /srv/bench/tls/cert.pem
  SSLCertificateKeyFile /srv/bench/tls/key.pem
</VirtualHost>

{
  admin off
  auto_https off
  default_sni 127.0.0.1
  servers {
    protocols h1 h2
  }
}
https://127.0.0.1:18446 {
  tls /srv/bench/tls/cert.pem /srv/bench/tls/key.pem
  encode zstd gzip
  handle_path /proxy/* {
    reverse_proxy 127.0.0.1:18893
  }
  root * /srv/bench/www
  php_fastcgi /app/* unix//run/bench/php-b.sock
  file_server {
    precompressed br zstd gzip
  }
}
http://127.0.0.1:18894 {
  handle_path /proxy/* {
    reverse_proxy 127.0.0.1:18893
  }
}