NGINX vs Apache Benchmark 2026: Performance, Memory and Real-World Throughput

NGINX vs Apache is the oldest argument in the web server world, and it’s still worth having in 2026 — because the answer has changed as workloads have evolved. The raw benchmarks still look the same: NGINX wins on static file serving and concurrency, Apache wins on compatibility and .htaccess magic. But the real-world picture is more nuanced, and there are scenarios where each one genuinely shines.

This post looks at the 2026 state of play: architecture differences, benchmark numbers for different workloads, memory profiles, PHP-FPM integration, and the cases where you should actually pick Apache over NGINX.

Architecture: Why They Differ Under Load

The performance difference between NGINX and Apache isn’t a build quality thing — it’s an architectural choice made in the 1990s that still has consequences today.

Apache’s threading model: Apache traditionally spawns a new thread (or process, depending on MPM) per connection. Each connection occupies a thread for its entire lifetime. Threads have memory overhead (~2–8MB each for mpm_worker, depending on configuration). Under high concurrency, memory usage scales linearly with connection count. Apache 2.4 with mpm_event is considerably better than the old prefork model, but the fundamental connection-to-thread mapping remains.

NGINX’s event loop model: NGINX uses a fixed number of worker processes (typically equal to CPU core count). Each worker runs a non-blocking event loop that can handle thousands of simultaneous connections. A connection that’s waiting for network I/O doesn’t occupy a thread — the worker picks up where it left off when data arrives. Memory usage scales logarithmically with connection count, not linearly.

In practice: on a server with 10,000 simultaneous connections, Apache mpm_event might use 3–5GB of RAM. NGINX might use 200–400MB for the same load. This architectural difference becomes the dominant factor at high concurrency.

Benchmark Results: Static Files

This is the workload that most clearly shows NGINX’s advantage. Serving static HTML, CSS, JS, and images — no application logic, no backend:

At low concurrency, the difference is marginal. Apache is a perfectly capable web server when it has headroom. The divergence becomes dramatic at high concurrency — Apache runs out of threads and starts queuing connections; NGINX handles them in the same event loop.

Memory at 10,000 concurrent connections: NGINX ~280MB, Apache ~4.2GB.

Benchmark Results: PHP-FPM Workloads

Modern PHP hosting — whether Apache or NGINX — typically uses PHP-FPM as a separate process pool. The web server proxies FastCGI requests to FPM. This levels the playing field considerably: both servers spend most of their time waiting for PHP-FPM to respond, and PHP-FPM performance dominates the numbers.

The PHP-FPM story: almost identical. When PHP-FPM is the bottleneck (which it is for uncached dynamic pages), both servers perform within a few percent of each other. NGINX’s event loop advantage matters much less when worker threads are blocked waiting for PHP anyway.

NGINX does maintain a consistent ~5–8% edge even with PHP-FPM, because it’s more efficient at maintaining the connection with the client while waiting for FPM to respond. But this is not a “one server is 3x faster” situation for PHP workloads.

Benchmark Results: TLS Handshake Performance

TLS setup overhead matters for latency, especially for new connections and CDN cache misses. Testing with TLS 1.3, ECDSA P-256 certificates, no session resumption:

The myguard NGINX package’s advantage here comes from openssl-nginx with kTLS kernel offload and the ec_nistp_64_gcc_128 optimized elliptic curve implementations. Apache uses system OpenSSL; NGINX from official Debian repos uses system OpenSSL; NGINX from myguard uses its dedicated optimized build.

Memory Under Sustained Load

Testing with 2,000 sustained concurrent connections over 10 minutes, primarily PHP-FPM workload:

• NGINX: ~90MB baseline, grows to ~130MB at 2k concurrent. Stays flat.
• Apache mpm_event: ~450MB baseline (pre-spawned threads), ~620MB at 2k concurrent. Also fairly stable once threads are spawned.
• Apache mpm_prefork (legacy): ~800MB baseline, ~1.4GB at 2k concurrent. Linear scaling — don’t use this for PHP anymore.

Apache mpm_event is significantly better than people who haven’t used Apache recently expect. The gap to NGINX is real but not catastrophic for typical server memory budgets.

Where Apache Genuinely Wins

Apache’s advantages aren’t just legacy baggage — some are real and still matter in 2026:

.htaccess Per-Directory Configuration

Apache reads and applies .htaccess files in any directory. NGINX doesn’t have this concept at all — all config is centralized in the server block. For shared hosting where tenants need to add custom rules, redirects, or password protection without server admin access, Apache is the natural fit. NGINX requires root access to reload config.

mod_php Integration

Apache with mod_php runs PHP as a module inside the Apache process. Simpler to configure, works with .htaccess PHP directives. In 2026 this is considered a legacy architecture (PHP-FPM is better on every metric), but it’s still common in legacy hosting environments and shared hosting panels like cPanel.

mod_rewrite Compatibility

If you’re running older applications with complex .htaccess rewrite rules, porting them to NGINX is a manual process. NGINX’s rewrite and location directives are more powerful but use completely different syntax. Apache is the zero-effort choice for legacy app migration.

Windows Compatibility

NGINX on Windows works but is a second-class citizen — limited worker process support, reduced performance. Apache on Windows is a first-class, well-tested deployment. If your stack involves Windows servers, Apache is the more practical choice.

When to Choose NGINX

NGINX is the better choice for:

• High-concurrency sites: If you regularly see thousands of simultaneous connections, NGINX’s event loop model is worth the switch
• Reverse proxy / load balancer: NGINX’s upstream module is more feature-rich and better-tuned for proxy workloads
• Static site / media serving: NGINX is faster and uses less memory
• HTTP/3 and QUIC: NGINX from the myguard repository has first-class HTTP/3; Apache’s HTTP/3 support is still experimental
• Resource-constrained servers (VPS with 1-2GB RAM): NGINX’s lower baseline memory footprint matters on small machines
• Modern greenfield deployments: NGINX has a cleaner configuration model for new projects

When to Choose Apache

Apache is the better choice for:

• Shared hosting / multi-tenant setups: .htaccess is irreplaceable for tenant-level config without root access
• Legacy application migration: .htaccess rewrite rules port over zero-effort
• Windows server deployments: Apache is much better tested on Windows
• Teams already expert in Apache: Familiarity and existing tooling are real advantages
• Moderate traffic, complex per-directory rules: The operational simplicity of .htaccess outweighs performance advantages at moderate scale

Angie: The Third Option Worth Considering

Angie is a fork of NGINX maintained by the original NGINX core team, with better performance numbers than either NGINX or Apache. It adds native ACME (automatic Let’s Encrypt without Certbot), a JSON monitoring API, and monthly release cadence. If you’re choosing a server for a new project and don’t need Apache’s .htaccess features, Angie is worth evaluating alongside NGINX.

Frequently Asked Questions

Related Posts

• NGINX Dynamic Modules Overview — the 50+ modules that make NGINX the more feature-rich option
• Angie Web Server: The Complete Guide — the NGINX fork with better performance and native ACME
• NGINX Performance and Security Expert Guide — how to get every last bit of performance from NGINX
• TLS Configuration Guide — A+ SSL Labs config that works with NGINX and Angie
• How to Enable HTTP/3 on NGINX — QUIC setup guide where NGINX leads Apache by years