{"id":557,"date":"2026-07-03T22:02:39","date_gmt":"2026-07-03T22:02:39","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=557"},"modified":"2026-08-17T22:13:21","modified_gmt":"2026-08-17T22:13:21","slug":"speed-up-vps-web-server-nginx-php-fpm-redis-caching","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/speed-up-vps-web-server-nginx-php-fpm-redis-caching\/","title":{"rendered":"Nginx, PHP-FPM, and Redis Tuning That Actually Speeds Up a VPS"},"content":{"rendered":"\n

Most “my VPS is slow” reports end with the same root cause: not a weak CPU or saturated network, but a web stack configured with defaults that assume more memory than the box has. Nginx, PHP-FPM, and Redis each have a handful of settings that decide whether a 2 GB VPS serves a busy site comfortably or swaps itself into a crawl. Before sizing anything, sanity-check the host itself against the plans on our VPS comparison table<\/a> \u2014 tuning cannot manufacture RAM that was never allocated.<\/p>\n\n\n\n

Measure First: Where Is the Time Going?<\/h2>\n\n\n\n

Capture a baseline before changing anything, so you can prove the effect of each tweak:<\/p>\n\n\n\n

# Total request time, plus a breakdown\ncurl -o \/dev\/null -s -w 'connect: %{time_connect}s\\n'\n     -w 'ttfb:    %{time_starttransfer}s\\n'\n     -w 'total:   %{time_total}s\\n' https:\/\/your-vps.example\/\n\n# Where memory actually goes\nfree -h\nps aux --sort=-%mem | head -12<\/code><\/pre>\n\n\n\n
If TTFB is high but the page itself is small, the delay is almost always PHP-FPM waiting for a free worker, or PHP waiting on a slow query \u2014 not Nginx. If TTFB is fine but total time is high, look at assets and caching next. Tune the layer the numbers point at.<\/p>\n\n\n\n
PHP-FPM: Size the Pool with Memory Math, Not Guesses<\/h2>\n\n\n\n
The single most impactful PHP-FPM setting is pm.max_children<\/code>. The default pm = dynamic<\/code> with max_children = 50<\/code> assumes far more memory than a small VPS has. Do the arithmetic:<\/p>\n\n\n\n
# Average RSS of one PHP-FPM worker under load\nps -o rss= -C php-fpm8.2 | awk '{s+=$1; n++} END {printf \"avg RSS: %.0f MB (%d workers)\\n\", s\/n\/1024, n}'<\/code>\n\n\n\n
Suppose workers average 80 MB and your box has 2 GB total with Nginx, MySQL, and Redis claiming roughly 800 MB. That leaves about 1.2 GB for PHP, so pm.max_children = 15<\/code> (15 \u00d7 80 MB = 1.2 GB) is the honest ceiling \u2014 not 50. Set pm = ondemand<\/code> for low-traffic sites so idle workers are freed instead of parked, and enable the slow log to find the scripts that hold workers hostage:<\/p>\n\n\n\n
pm = ondemand\npm.max_children = 15\npm.process_idle_timeout = 10s\nslowlog = \/var\/log\/php-fpm-slow.log\nrequest_slowlog_timeout = 5s<\/code><\/pre>\n\n\n\n
Watch tail -f \/var\/log\/php-fpm-slow.log<\/code> for a week. If the same function appears repeatedly, fix the query or cache its result \u2014 raising max_children<\/code> to paper over a slow script just moves the problem to the OOM killer.<\/p>\n\n\n\n
Nginx: Small Changes, Measurable Gains<\/h2>\n\n\n\n