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: 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.
Practice what you learned
1. What was the primary problem Nginx was designed to solve when it was released in 2004?
2. Why does Apache's .htaccess mechanism add overhead compared to Nginx's configuration model?
3. Which Apache MPM spawns one process per connection, offering strong isolation but higher memory use?
4. How does Nginx typically apply a configuration change?
5. What is a common hybrid deployment pattern combining Nginx and Apache?
Was this page helpful?
You May Also Like
Nginx as an API Gateway
How to use Nginx to route, rate-limit, authenticate, and load balance API traffic across backend services without a dedicated gateway product.
Deploying a Web App Behind Nginx
A practical walkthrough of putting Nginx in front of an application server: reverse proxying, TLS termination, static asset serving, and process management.
Nginx Quick Reference
A condensed reference of essential Nginx commands, directives, and configuration patterns for daily operational use.
Related Reading
Related Study Notes in DevOps
Browse all study notesAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics
DevOpsCI/CD Tools & Pipelines Study Notes
YAML · 37 topics