Nginx vs Apache

Analogy categoryAnalogies

Nginx vs Apache: Two Philosophies for Serving the Web

Nginx and Apache HTTP Server both serve enormous volumes of web traffic, but they solve the connection-handling problem in fundamentally different ways. Apache, released in 1995, uses a process-or-thread-per-connection model with a deep module ecosystem and per-directory .htaccess overrides. Nginx, released in 2004 to address the C10K problem, uses a small number of event-driven worker processes that multiplex thousands of connections asynchronously in a single thread each. This architectural split explains almost every practical difference between them, from memory footprint to how configuration is written and reloaded.

🏏

Cricket analogy: It is the difference between fielding one dedicated player per incoming ball versus MS Dhoni behind the stumps tracking every delivery, run-out chance, and bowler change simultaneously without needing extra hands.

Architecture: Event Loop vs Process-Per-Connection

Nginx's master process reads nginx.conf and spawns a fixed number of worker processes, typically one per CPU core, set via worker_processes. Each worker runs a non-blocking event loop built on epoll (Linux) or kqueue (BSD), so a single worker can hold open thousands of idle keep-alive connections while only spending CPU on the ones with actual I/O ready. There is no thread-per-request overhead, no context-switching cost per connection, and memory use per connection stays in the low kilobytes, which is why Nginx scales well for reverse proxying, static assets, and long-lived connections like WebSockets or Server-Sent Events.

🏏

Cricket analogy: One Nginx worker per core is like a single wicketkeeper covering all ends of the ground, using epoll the way a keeper reads bowler cues to react only when the ball actually comes toward the stumps.

Apache's Multi-Processing Modules (MPMs) determine how it handles concurrency. The classic prefork MPM spawns one process per connection, which is memory-heavy but keeps each request fully isolated, useful for non-thread-safe modules like older mod_php. The worker MPM uses threads within processes to reduce memory overhead, and the newer event MPM decouples keep-alive connections from worker threads, borrowing ideas closer to Nginx's model. Because each Apache process or thread often loads the full PHP interpreter and its extensions in-process, memory per connection is typically far higher than Nginx, and a traffic spike can exhaust available processes faster than it exhausts Nginx's worker capacity.

🏏

Cricket analogy: Prefork MPM isolating every connection in its own process is like a franchise league fielding an entirely fresh playing eleven for every single match instead of reusing a settled squad.

Configuration Philosophy: Central nginx.conf vs Distributed .htaccess

Apache allows per-directory .htaccess files that let individual application owners override rewrite rules, authentication, and headers without touching the main server config or restarting the server, which is convenient on shared hosting but forces Apache to check for and parse .htaccess files on every single request down the directory tree, adding real I/O overhead. Nginx has no equivalent mechanism by design: all routing, rewrite, and access-control logic lives in nginx.conf and per-site config files, loaded once and applied from memory. Changes require a config test (nginx -t) and a reload (nginx -s reload), which is a deliberate trade of flexibility for speed and predictability.

🏏

Cricket analogy: Apache's .htaccess is like allowing each ground curator to tweak pitch conditions match by match, while Nginx is more like a single ICC playing-conditions document fixed centrally before the tournament starts.

A very common production pattern is running Nginx in front of Apache: Nginx terminates TLS, serves static files directly, and reverse-proxies dynamic requests to Apache, which still handles legacy .htaccess rules and mod_php-based applications. This hybrid gives you Nginx's connection-handling efficiency at the edge without rewriting an existing Apache-dependent application.

Performance and Module Ecosystem

Under high concurrency, especially with many slow or idle keep-alive clients, Nginx typically uses less memory and CPU than Apache because of its event-driven model, which is why it dominates as a reverse proxy, load balancer, and static file server in front of application servers written in any language. Apache's advantage has historically been its module ecosystem, particularly mod_php running the PHP interpreter in-process for very low per-request latency on PHP-heavy sites, and mod_security for in-process web application firewalling. Modern PHP deployments increasingly use PHP-FPM behind Nginx instead, narrowing that historical gap considerably.

🏏

Cricket analogy: Nginx handling many idle connections cheaply is like a T20 side rotating bowlers efficiently across twenty overs, while mod_php in-process is like a specialist all-rounder who bats and bowls without ever leaving the field.

Nginx modules are largely compiled in at build time; you cannot simply apt-get install an arbitrary third-party module the way you can enable an Apache module with a2enmod. A small set of official modules (like ngx_http_perl_module or some balancer modules) support dynamic loading since Nginx 1.9.11, but most custom modules require compiling Nginx from source with --add-module, or using a distribution that already bundles the module you need.

nginx

# Nginx: static site + reverse proxy to an app server
server {
    listen 80;
    server_name example.com;

    location /static/ {
        alias /var/www/example/static/;
        expires 30d;
    }

    location /api/ {
        proxy_pass http://127.0.0.1:5000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

# Equivalent Apache VirtualHost using mod_proxy
<VirtualHost *:80>
    ServerName example.com
    DocumentRoot /var/www/example

    Alias /static/ /var/www/example/static/

    ProxyPass /api/ http://127.0.0.1:5000/
    ProxyPassReverse /api/ http://127.0.0.1:5000/
</VirtualHost>

Nginx uses a fixed number of event-driven worker processes with async, non-blocking I/O; Apache traditionally uses one process or thread per connection via its MPMs.
Nginx generally uses far less memory per connection, making it better suited to high-concurrency workloads and many idle keep-alive clients.
Apache's .htaccess allows decentralized, per-directory config overrides at the cost of per-request filesystem checks; Nginx centralizes all config in nginx.conf, loaded once.
Config changes in Nginx require a syntax test (nginx -t) and a reload (nginx -s reload); Apache's .htaccess changes apply immediately without a restart.
A common production pattern runs Nginx in front of Apache as a reverse proxy and static file server, combining Nginx's efficiency with Apache's legacy module support.
Nginx modules are mostly compiled at build time, unlike Apache's a2enmod-style dynamic module loading, so custom modules often require building from source.
Modern PHP deployments increasingly pair Nginx with PHP-FPM, narrowing Apache's historical mod_php latency advantage.