Tuning Apache/Nginx and server resources for Drupal workloadsfor Drupal 11 , 10 , 9 , and 8

Home » Performance Optimization » Tuning Apache/Nginx and server resources for Drupal workloads
Last updated :  
11.x , 10.x , 9.x , 8.x

Every setting covered so far in this section — OpCache, PHP-FPM, HTTP/2, Varnish — assumes the underlying server actually has the CPU, memory, and disk I/O to support them. Tuning software configuration on a resource-starved server is like optimizing a recipe for a stove that can't get hot enough — the ceiling is physical, not configuration.

What you'll learn in this lesson

  • The three resources that matter most for a Drupal workload specifically
  • Why disk I/O is the resource people underestimate most
  • How to identify which resource is actually your bottleneck before tuning blindly

CPU: mostly about PHP execution and database queries

Drupal's CPU load comes overwhelmingly from PHP execution (mitigated by OpCache, as covered earlier) and database query processing. A CPU-bound Drupal site usually shows itself as consistently high load average even when memory and disk have headroom — check with top or htop under real traffic, not synthetic idle-server numbers.

Memory: sized for your actual PHP-FPM pool

# Total memory budget check:
# (pm.max_children × average process size) + database server memory
#   + OS overhead should stay comfortably under total RAM.
free -m
cat /proc/meminfo | grep MemAvailable

This directly ties back to the PHP-FPM sizing lesson earlier — an undersized server makes correct PHP-FPM tuning impossible no matter how carefully you calculate pm.max_children.

Disk I/O: the resource people forget

Why disk I/O matters more than people expect: Drupal's file cache, image style derivative generation, session storage (if file-based), and the database's own disk operations all depend on disk speed. On cheap spinning-disk hosting, a burst of image-derivative generation (a visitor hitting many never-before-generated responsive image sizes at once) can cause a genuine, measurable slowdown that has nothing to do with PHP or the database at all. SSD-backed storage is close to mandatory for any Drupal site with real traffic.

Finding your actual bottleneck first

# Don't tune blind — measure which resource is actually constrained.
vmstat 1 10      # CPU/memory/swap activity over 10 seconds
iostat -x 1 10   # disk I/O wait specifically
htop             # live per-process CPU/memory view

A high "wa" (I/O wait) percentage in vmstat output points at disk, not CPU or memory — tuning PHP-FPM further wouldn't help that bottleneck at all. Always measure before reaching for a specific fix.

Quick check: vmstat shows low CPU usage, plenty of free memory, but a consistently high I/O wait percentage during traffic spikes. Would adding more PHP-FPM workers help? If you said no — more workers competing for the same slow disk would likely make I/O wait worse, not better — you've understood why measuring the actual bottleneck matters more than tuning by habit.

Key takeaways

  • Software tuning has a hard ceiling set by actual server resources — measure before assuming a config change will help.
  • CPU load on Drupal comes mainly from PHP execution and database queries.
  • Memory budget must account for your full PHP-FPM pool plus the database server plus OS overhead, not PHP alone.
  • Disk I/O is the most commonly overlooked bottleneck — SSD storage matters for image derivatives, sessions, and database operations alike.
  • vmstat/iostat/htop tell you which resource is actually constrained before you spend time tuning the wrong one.

Coming up next

You've now covered every layer of server-side tuning this tutorial addresses directly. Last in this section: offloading static assets to a CDN, moving load off your server entirely rather than tuning it in place.