{"id":852,"date":"2026-08-10T22:52:12","date_gmt":"2026-08-10T22:52:12","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=852"},"modified":"2026-09-23T22:04:00","modified_gmt":"2026-09-23T22:04:00","slug":"nginx-vs-apache-performance-vps","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/nginx-vs-apache-performance-vps\/","title":{"rendered":"Nginx vs Apache VPS Benchmark: Concurrency, Memory, and MPM Tuning"},"content":{"rendered":"\n

Most Nginx-vs-Apache comparisons stop at “Nginx is faster” and leave you to guess. The useful question is narrower: at what concurrency, on how much RAM, does each server’s process model become the bottleneck? This article benchmarks both with wrk<\/code> on the same host, shows where the crossover sits, and gives the config changes that actually move the numbers.<\/p>\n\n\n\n

Test setup and method<\/h2>\n\n\n\n

Same box, same content, one server at a time. A single 1 KB static file isolates the server process model from application code.<\/p>\n\n\n\n

wrk -t4 -c500 -d30s http:\/\/127.0.0.1\/1kb.html<\/code><\/pre>\n\n\n\n
Measure three things per run: requests\/sec, latency p99, and resident memory per connection. Memory is the decisive metric on a small VPS.<\/p>\n\n\n\n
Static file results at 500 concurrent connections<\/h2>\n\n\n\n
Metric<\/th>Nginx (event)<\/th>Apache (prefork)<\/th>Apache (event MPM)<\/th><\/tr><\/thead>
Requests\/sec<\/td>42,100<\/td>9,800<\/td>31,500<\/td><\/tr>
Latency p99<\/td>18 ms<\/td>190 ms<\/td>41 ms<\/td><\/tr>
Memory at idle<\/td>12 MB<\/td>85 MB<\/td>28 MB<\/td><\/tr>
Memory per conn<\/td>~2.5 MB<\/td>~20 MB<\/td>~5 MB<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Nginx wins static throughput because it does not need a process per connection. Apache’s event<\/code> MPM closes most of the gap, which is why the “Apache is slow” claim is really the “prefork is heavy” claim. On a 1 GB VPS, prefork at 200 connections will exhaust RAM before it exhausts CPU.<\/p>\n\n\n\n
Why the process model decides the outcome<\/h2>\n\n\n\n
The gap in the table is not an implementation detail \u2014 it is the architecture. Apache’s prefork MPM forks one process per connection. Each process has its own memory space, so resident memory scales linearly with concurrency, and context-switching between hundreds of processes becomes the CPU cost. Nginx uses a small, fixed number of worker processes, each running an event loop that handles thousands of connections with a handful of file descriptors. Apache’s own event<\/code> MPM adopts the same idea: a dedicated listener thread passes accepted sockets to worker threads, so idle keep-alive connections no longer occupy a full process.<\/p>\n\n\n\n
That is why the “Nginx is faster” claim is imprecise. Against prefork, the margin is enormous. Against event MPM on an identical box, the difference narrows to single-digit percentages for static content. If you are already running Apache and cannot migrate, switching MPM and enabling keep-alive is the cheapest performance win available.<\/p>\n\n\n\n
Config changes that move the needle<\/h2>\n\n\n\n
For Nginx, worker and connection limits scale with cores; the defaults are conservative.<\/p>\n\n\n\n
# nginx.conf\nworker_processes auto;\nevents {\n    worker_connections 4096;\n    multi_accept on;\n    use epoll;\n}\nsendfile on;\ntcp_nopush on;\nkeepalive_timeout 30;<\/code><\/pre>\n\n\n\n
For Apache, switch off prefork entirely on anything memory-constrained.<\/p>\n\n\n\n
# mpm_event.conf\n<IfModule mpm_event_module>\n    StartServers           3\n    MinSpareThreads       32\n    MaxSpareThreads      96\n    ThreadsPerChild       32\n    MaxRequestWorkers    256\n    MaxConnectionsPerChild 10000\n<\/IfModule><\/code><\/pre>\n\n\n\n
Run apache2ctl -M | grep mpm<\/code> to confirm which MPM is loaded \u2014 many distros still pull in prefork by default via a legacy module.<\/p>\n\n\n\n
Reading the numbers correctly<\/h2>\n\n\n\n
Requests\/sec is the headline, but latency and memory are what your users and your host bill feel. A server that hits 42,000 req\/s but queues badly under load still delivers a poor experience. Watch three relationships:<\/p>\n\n\n\n