If your site gets a few thousand visits a day, both Nginx and Apache will serve it comfortably \u2014 neither is too slow for the job. The decision is therefore not about raw throughput. It is about which one costs you less in memory, configuration effort, and ongoing maintenance on the hardware you actually have.<\/p>\n\n\n\n
This comparison focuses on a realistic low-traffic deployment: a single small server, a handful of sites, dynamic content from PHP or a similar runtime, and one administrator who wants things to keep working without babysitting.<\/p>\n\n\n\n
Apache historically forks or spawns a process or thread per connection. Nginx uses an event-driven model where a small, fixed number of worker processes handle thousands of concurrent connections. On a large server the difference is throughput; on a small server the difference is memory.<\/p>\n\n\n\n
Measure it directly rather than taking anyone’s word for it. On a fresh install with no traffic, compare resident memory:<\/p>\n\n\n\n
# Nginx: typical idle footprint\nps -o rss= -C nginx | awk '{s+=$1} END {print s\/1024\" MB\"}'<\/p>\n\n\n\n# Apache with prefork and a modest MaxRequestWorkers\nps -o rss= -C apache2 | awk '{s+=$1} END {print s\/1024\" MB\"}'<\/code><\/pre><\/p>\n\n\n\n
Nginx typically idles at 5\u201315 MB total. Apache with prefork and a few dozen workers can idle at 100\u2013200 MB because each worker is a full process. On a 1 GB server, that difference is a large fraction of your available RAM \u2014 memory that could otherwise be a database buffer pool or a PHP OPcache.<\/p>\n\n\n\n
When Apache Is the Better Choice on a Small Server<\/h2>\n\n\n\n
Memory is not the only currency. Apache has real advantages that matter more than a 100 MB difference for some setups:<\/p>\n\n\n\n
\n.htaccess<\/code> support<\/strong> \u2014 if you host applications that manage their own rewrite rules (many PHP CMSs and e-commerce platforms ship .htaccess<\/code> files), Apache works out of the box. Nginx cannot read .htaccess<\/code>; every rule must be converted into server config.<\/li>\n- Modular legacy features<\/strong> \u2014
mod_rewrite<\/code> with per-directory context, basic auth, and directory listing behaviours are all available without translation.<\/li>\n- Simpler mental model for one site<\/strong> \u2014 if you run exactly one application on one vhost, the configuration burden of Nginx is low and the event model is a pure win.<\/li>\n
- Extensive documentation and community answers<\/strong> \u2014 for an unusual configuration, you will find more copy-paste-ready Apache examples than Nginx ones.<\/li>\n<\/ul>\n\n\n\n
When Nginx Wins<\/h2>\n\n\n\n\n- Serving static assets and many small files<\/strong> \u2014 Nginx’s
sendfile<\/code> and event loop are extremely efficient here.<\/li>\n- Acting as a reverse proxy or load balancer<\/strong> \u2014
proxy_pass<\/code> and upstream blocks are first-class, and this is the most common reason people switch.<\/li>\n- Hosting several sites on minimal RAM<\/strong> \u2014 one Nginx process handles all vhosts; each Apache vhost adds to the same worker pool but you are already paying the process overhead.<\/li>\n
- Predictable memory under traffic spikes<\/strong> \u2014 Nginx’s worker count is fixed, so a connection flood does not balloon memory the way an Apache prefork pool can.<\/li>\n<\/ul>\n\n\n\n
The Configuration Cost of Switching<\/h2>\n\n\n\n
The honest cost of Nginx on a low-traffic site is the one-time conversion of rewrite rules. A typical WordPress .htaccess<\/code> becomes:<\/p>\n\n\n\nlocation \/ {\n try_files $uri $uri\/ \/index.php?$args;\n}<\/p>\n\n\n\nlocation ~ \\.php$ {\n include snippets\/fastcgi-php.conf;\n fastcgi_pass unix:\/run\/php\/php8.2-fpm.sock;\n fastcgi_read_timeout 120;\n}<\/code><\/pre><\/p>\n\n\n\n
Note the second block: Nginx does not execute PHP itself; it passes requests to PHP-FPM over a socket. That is an extra service to keep running, but it also means PHP workers are a separate, tunable pool \u2014 which is an advantage on a small server, because you can size PHP memory independently of the web server.<\/p>\n\n\n\n
Apache’s equivalent is mod_php<\/code> or php-fpm<\/code> via mod_proxy_fcgi<\/code>. Modern practice on small servers is PHP-FPM for both, so this is close to a wash if you are starting fresh.<\/p>\n\n\n\nPractical: Tuning Whichever You Choose<\/h2>\n\n\n\n
For Apache on a small server, use the event MPM rather than prefork if your modules allow it, and set worker counts against available RAM rather than leaving defaults:<\/p>\n\n\n\n
# \/etc\/apache2\/mods-available\/mpm_event.conf\n<IfModule mpm_event_module>\n StartServers 2\n MinSpareThreads 10\n MaxSpareThreads 30\n ThreadsPerChild 15\n MaxRequestWorkers 45\n MaxConnectionsPerChild 10000\n<\/IfModule><\/code><\/pre>\n\n\n\nFor Nginx, size workers to CPU cores and cap connections per worker so you fail predictably rather than running out of memory:<\/p>\n\n\n\n
# \/etc\/nginx\/nginx.conf\nworker_processes auto;\nevents {\n worker_connections 1024;\n multi_accept on;\n}\nclient_body_buffer_size 16k;\nclient_max_body_size 32m;\nkeepalive_timeout 30;<\/code><\/pre>\n\n\n\nIn both cases, put a FastCGI or proxy cache in front of dynamic content. On a low-traffic site this matters more than the web server choice, because caching a page means the request never reaches PHP at all.<\/p>\n\n\n\n
A Decision Rule You Can Apply Today<\/h2>\n\n\n\n