PHP-FPM OnDemand vs Dynamic: Best Pool Settings for VPS

When your web application starts experiencing slower load times during traffic spikes, the first instinct is often to upgrade your VPS hardware. However, before spending more on CPU and RAM, look closely at how your web stack handles requests. For PHP applications running on Nginx or Apache, PHP-FPM (FastCGI Process Manager) sits at the heart of performance. If your PHP-FPM pools are not configured correctly, your server may struggle under load even when hardware resources are underutilized.

In this guide, we will look at how PHP-FPM process managers work, compare the ondemand and dynamic modes, and walk through configuring your VPS to handle concurrent traffic efficiently.

Understanding PHP-FPM Architecture and Pools

PHP-FPM operates as an alternative PHP FastCGI implementation with features useful for heavily loaded sites. It manages pools of worker processes to parse PHP code and return generated pages to the web server.

A "pool" is a separate grouping of worker processes defined in your configuration files. Each pool can run under a different user, have its own resource limits, and be tuned for specific applications. By default, configuration files are typically located in /etc/php/[version]/fpm/pool.d/www.conf on Ubuntu systems.

The core challenge in pool tuning is balancing resource consumption and response time. Too many processes will exhaust your VPS memory, leading to swapping and severe slowdowns. Too few processes will cause incoming requests to queue up, resulting in HTTP 504 Gateway Timeouts for your users.

Process Manager Options: Static vs. Dynamic vs. Ondemand

PHP-FPM provides three process management (pm) strategies:

• Static: Allocates a fixed number of child processes (pm = static). This mode is straightforward but consumes memory constantly, making it inefficient for fluctuating traffic on a standard VPS.
• Dynamic: Spawns a baseline number of child processes at startup, then dynamically scales the number of processes up and down based on workload (pm = dynamic).
• Ondemand: Does not spawn any children at startup. Instead, processes are created as connection requests arrive, and terminated after an idle timeout (pm = ondemand).

For most general-purpose VPS environments, dynamic and ondemand are the primary contenders. Choosing the right one depends heavily on your traffic patterns and available RAM.

When to Use the Ondemand Process Manager

The ondemand process manager is conservative with system resources. It is ideal for development servers, low-traffic sites, or multi-tenant VPS environments where you host several small applications that sit idle for long periods.

Because child processes are only created when a request comes in, idle pools consume virtually zero CPU and minimal memory. However, this comes with a minor trade-off: the first request after an idle period may experience a tiny fractional delay while the master process spawns a new worker.

To configure ondemand, open your pool configuration file on Ubuntu 24.04 LTS (adjust the PHP version number to match your installation):

sudo nano /etc/php/8.3/fpm/pool.d/www.conf

Locate and adjust the following directives:

pm = ondemand
pm.max_children = 50
pm.process_idle_timeout = 10s;
pm.max_requests = 500

• pm = ondemand: Enables the ondemand manager.
• pm.max_children: The maximum number of child processes that can be alive at the same time.
• pm.process_idle_timeout: The number of seconds after which an idle process is killed.
• pm.max_requests: The number of requests each child process should execute before respawning, which helps prevent memory leaks in third-party libraries.

Configuring the Dynamic Process Manager for High Traffic

If your website receives steady or predictable traffic spikes, the dynamic process manager is usually the better choice. It keeps a pool of workers ready to respond instantly, eliminating the small spawn-time penalty of the ondemand mode.

Configuring dynamic requires careful math based on your VPS RAM. Each PHP-FPM process consumes a measurable amount of memory. To find out how much memory your processes use, you can run diagnostic commands on your Ubuntu 24.04 server:

ps --no-headers -o "rss,cmd" -C php-fpm8.3 | awk '{ sum+=$1 } END { print "Average process size: " sum/NR/1024 " MB" }'

Once you know the average memory footprint of a single PHP process, calculate your pm.max_children by taking the total RAM dedicated to PHP, leaving headroom for the OS, Nginx, and database services, and dividing it by that average size.

Open your pool configuration file:

sudo nano /etc/php/8.3/fpm/pool.d/www.conf

Set the dynamic parameters conservatively to match your VPS limits:

pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 500

• pm.start_servers: The number of child processes created on startup.
• pm.min_spare_servers: The minimum number of idle child processes maintained. If idle processes drop below this, new ones are created.
• pm.max_spare_servers: The maximum number of idle child processes. Excess idle processes are cleaned up.

Testing and Applying Your Configuration Changes

After saving your configuration changes, it is essential to test the syntax before restarting the service to avoid downtime.

On Ubuntu 24.04 LTS, run the following command to check for syntax errors in your PHP-FPM configuration:

sudo php-fpm8.3 -t

If the output confirms that the configuration file test is successful, restart the PHP-FPM service to apply your changes:

sudo systemctl restart php8.3-fpm

Monitor your server's resource utilization using tools like htop or by checking the system logs to ensure that memory usage remains stable under load and that processes scale as expected.

Always make incremental adjustments to your pool settings. Changing limits drastically without monitoring can cause unexpected memory exhaustion or dropped connections during peak traffic hours.

Conclusion

Optimizing your PHP-FPM pools is a straightforward way to extract better performance out of your VPS environment without touching your hardware infrastructure. By choosing ondemand for low-resource or multi-site setups, or carefully calculating your limits for dynamic mode under heavy concurrent traffic, you protect your application from slowdowns and server crashes. Take the time to measure your memory usage, test your configuration changes carefully, and keep your site running smoothly for every visitor.