PHP-FPM tuning: Using 'pm static' for Max Performance

Key Points

• For adequate memory servers, the pm static setting of PHP-FPM provides high throughput and low latency. This setting allows PHP-FPM processes to maintain maximum capacity at all times, enabling rapid response to traffic peaks without the need to generate new processes.
• Using pm static Careful adjustment is required to avoid insufficient memory or cache stress issues. pm.max_children It should be set according to the maximum number of PHP-FPM processes the server can handle without affecting CPU performance.
• For servers with multiple PHP-FPM pools or low memory, pm dynamic or pm ondemand may be more suitable. These settings can save memory by adjusting the number of subprocesses based on the current load, but can also cause overhead issues when traffic fluctuations are occurring.
• Regular monitoring and tuning of PHP-FPM configuration is essential for optimal performance regardless of the settings you choose. The average size of PHP-FPM processes varies from server to server and requires manual adjustment and a clear understanding of the server's resource and traffic patterns.

The original manuscript of the article was originally published on HaydenJames.io without editing and was reproduced here with permission from the author.

Let us quickly learn how to best set up PHP-FPM for high throughput, low latency, and more stable CPU and memory usage. By default, most settings set the PM (process manager) string of PHP-FPM to dynamic, and ondemand is usually recommended if you encounter available memory problems. However, let's compare these two management options based on the documentation of php.net and compare my favorite options for high traffic settings - static pm:

• pm = dynamic: The number of child processes is dynamically set according to the following instructions: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
• pm = ondemand: The process is generated on request as needed, which is different from dynamic, which starts at the service starts pm.start_servers.
• pm = static: The number of child processes is fixed by pm.max_children.

See the complete list of global php-fpm.conf directives for more details.

Similarities of PHP-FPM Process Manager (PM) and CPUFreq Regulator

This may seem a bit off topic, but I would like to associate it with our PHP-FPM tweaked topic. OK, we all have had slow CPU speeds at some point, whether it’s a laptop, a virtual machine, or a dedicated server. Remember CPU frequency scaling? (CPUFreq regulator.) These settings are available on both nix and Windows systems, and can improve performance and system responsiveness by changing the CPU regulator settings from ondemand to performance*. This time, let's compare the description and look for similarities:

• Governor = ondemand: Dynamically scale the CPU frequency according to the current load. Jump to the highest frequency and then decrease the frequency as the idle time increases.
• Governor = conservative: Dynamically scale the frequency according to the current load. Scaling frequency smoother than ondemand.
• Governor = performance: Always run the CPU at maximum frequency.

See the complete list of CPUFreq regulator options for more details.

Did you notice the similarity? I want to use this comparison first, with the goal of finding the best way to write an article, recommending pm static of PHP-FPM as your first choice.

For CPU regulators, the performance setting is a fairly safe performance boost, as it almost entirely depends on the limitations of your server CPU. Other factors are just side effects such as heat, battery life (laptop), and permanently setting the CPU frequency to 100%. Once set to performance, it is indeed the fastest setup for the CPU. For example, read about the force_turbo setting on the Raspberry Pi, which forces your RPi board to use a performance regulator, and performance improvements are more noticeable due to the low CPU clock speed.

Use pm staticAchieve maximum performance of the server

PHP-FPM pm static Settings depend heavily on how much memory the server has. Basically, if you're having problems with insufficient server memory, then pm ondemand or dynamic may be a better choice. On the other hand, if you have enough memory available, you can avoid most of the PHP Process Manager (PM) overhead by setting pm static to the maximum capacity of the server. In other words, when you do calculations, pm.static should be set to the maximum number of PHP-FPM processes that can run without creating memory availability or cache stress issues. Also, don't set it too high to overwhelm the CPU(s) and cause a lot of unprocessed PHP-FPM operations.

In the above image, the pm = static and pm.max_children = 100 of this server use up to about 10GB of 32GB of installed memory. Please note the highlighted columns of self-interpretation. During this screenshot, there were about 200 "active users" in Google Analytics (last 60 seconds). At this level, approximately 70% of PHP-FPM child processes are still idle. This means that PHP-FPM is always set to the maximum capacity of the server resource regardless of the current traffic. The idle process stays online, waiting for traffic peaks and responding immediately, instead of having to wait for pm to spawn child processes and then close it after pm.process_idle_timeout expires. I've set pm.max_requests very high because this is a production server without PHP memory leaks. If you have 110% confidence in current and future PHP scripts, you can use pm.max_requests = 0 in static. However, it is recommended to restart the script regularly. Set the number of requests to a higher number, because the point is to avoid pm overhead. For example, at least pm.max_requests = 1000, depending on your pm.max_children number and requests per second.

This screenshot is filtered using Linux top, by the “u” (user) option and the name of the PHP-FPM user. The number of processes displayed is only about 50 (no calculations), but basically top displays top-level statistics that suit your terminal window—in this case, sorted by %CPU. To view all 100 PHP-FPM processes, you can use the following command:

<code>top -bn1 | grep php-fpm</code>

When to use pm ondemand and dynamic

Using pm dynamic, you may have noticed errors similar to the following:

<code>WARNING: [pool xxxx] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 4 idle, and 59 total children</code>

You may try to increase/adjust settings, but you will still see the same error as someone described in the Serverfault post. In this case, pm.min is too low and it is difficult to adjust correctly because network traffic fluctuates greatly with troughs and peaks. The usual advice is to use pm dynamic. However, this is even worse because when there is little or no traffic, pm ondemand will shut down the idle process to 0, and then you will end up with as much overhead problem as the traffic fluctuates – unless, of course, you will be idle Timeout is set to extremely high... In this case you should only use ondemand highpm.static. pm.max_requests

However, when you have multiple PHP-FPM pools, PM dynamic, especially ondemand, can save you resources. For example, host multiple cPanel accounts or multiple websites under different pools. For example, I have a server that has over 100 cPanel accounts and about 200 domain names, pm.static and even dynamic do not do well. Only ondemand can execute well, as more than two-thirds of the websites have little traffic. Using ondemand, this means that all child processes will be shut down, saving a lot of server memory! Thankfully, cPanel developers have solved this problem and now it defaults to ondemand. Previously, due to the use of dynamic by default, it made PHP-FPM an option on a shared server even on an idle cPanel PHP-FPM pool/account. If you receive good traffic, you are unlikely to host on a server with a large number of PHP-FPM pools (shared hosts).

Conclusion

In PHP-FPM, once you start providing a large amount of traffic, the ondemand and dynamic process managers of PHP-FPM may limit throughput due to inherent overhead. Understand your system and set your PHP-FPM process to match the maximum capacity of the server. Start with the maximum usage setting based on pm dynamic or ondemand and increase to the point where the memory and CPU can handle without being overwhelmed. You will notice that using pm.max_children is because you let everything reside in memory, over time, the traffic peak will cause the CPU to peak and the server’s load and CPU average will be smoother. The average size of your PHP-FPM process varies by web server and needs to be adjusted manually, so why the more automated overhead process managers—pm static and dynamic—a more popular suggestion. Hope this article helps you. ondemand

Update: Added A/B benchmark comparison chart. Having PHP-FPM processes reside in memory helps improve performance, but at the cost of increasing memory usage to keep them in a wait state. Find the best point for your settings.

FAQs about PHP-FPM Adjustments (FAQ)

What is PHP-FPM and why is it important to my server performance?

PHP-FPM or FastCGI Process Manager is another PHP FastCGI implementation that has some additional features useful for sites of any size, especially for busy sites. It is important for server performance because it allows the server to handle more requests from simultaneous visitors by leveraging the worker pool. These processes are responsible for parsing PHP files, generating dynamic content and providing them to clients. By effectively managing these processes, PHP-FPM can significantly improve server performance and scalability.

How does PHP-FPM improve my website performance?

PHP-FPM improves website performance by effectively managing PHP processes. It uses the main process to control multiple child processes that process PHP scripts. This allows efficient use of server resources, as idle processes can be terminated and new processes can be generated as needed. Additionally, PHP-FPM supports opcode caching, which can significantly speed up PHP execution by storing precompiled script bytecode in shared memory, eliminating the need for PHP to load and parse scripts on every request.

What is the pm static configuration in PHP-FPM and how does it affect performance?

pm static in PHP-FPM The

configuration sets the number of child processes to a fixed number. This means that there will always be a specific number of processes ready to serve incoming requests regardless of the current server load. This can lead to better performance under high loads, as new processes are not required to be generated. However, it can also lead to higher memory usage, because they are always running even if these processes are not needed.

How to adjust PHP-FPM for maximum performance?

pm Adjusting PHP-FPM for maximum performance involves tuning multiple configuration settings. These settings include the pm.max_children settings that determine the process manager to use, and the pm.start_servers settings that set the maximum number of child processes. Other important settings include pm.min_spare_servers, pm.max_spare_servers and

, which control the number of servers started, the minimum number of idle servers, and the maximum number of servers respectively. Adjusting these settings to match the server's resource and traffic patterns can significantly improve performance.

What are some common problems with PHP-FPM and how can I troubleshoot it?

pm.max_childrenSome common problems with PHP-FPM include high CPU usage, slow response time, and errors related to reaching the maximum number of child processes. These problems can often be solved by adjusting the PHP-FPM configuration settings, such as adding

settings or switching to a different process manager. Additionally, monitoring tools can be used to identify bottlenecks and performance issues.

How does PHP-FPM compare to other PHP handlers?

PHP-FPM is generally considered to be more efficient and flexible than other PHP handlers. It supports various process managers and can be adjusted according to the server's resources and traffic patterns. Additionally, PHP-FPM supports opcode caching and can handle a large number of simultaneous requests, making it ideal for busy sites.

Can I use PHP-FPM with any web server?

Yes, PHP-FPM can be used with any web server that supports the FastCGI protocol. This includes popular web servers such as Apache, Nginx, and Lighttpd.

What is opcode caching and how does it improve PHP performance?

Opcode caching is a technology that improves PHP performance by storing precompiled script bytecode in shared memory. This eliminates the need for PHP to load and parse scripts on every request, reducing execution time.

How to monitor the performance of PHP-FPM?

Several tools are available for monitoring the performance of PHP-FPM. These tools include the PHP-FPM status page (which provides information about the current state of the worker process) and various command-line tools such as top and ps. In addition, there are some third-party monitoring solutions that provide more detailed metrics and alerts.

What are some best practices for using PHP-FPM?

Some best practices with PHP-FPM include: adjusting process manager settings to match the server's resource and traffic mode; enabling opcode caching; and regularly monitoring performance to identify and resolve issues. Additionally, be sure to keep PHP-FPM and web server software up to date to take advantage of the latest performance improvements and security fixes.

The above is the detailed content of PHP-FPM tuning: Using 'pm static' for Max Performance. For more information, please follow other related articles on the PHP Chinese website!