Shulou(Shulou.com)06/03 Report--

This article mainly explains "PHP-FPM multi-process model-related knowledge points". The explanation content in this article is simple and clear, and it is easy to learn and understand. Please follow the ideas of Xiaobian to study and learn "PHP-FPM multi-process model-related knowledge points" together.

First, let's look at a few questions:

①: What are the main ways for PHP-FPM to start the process, and what is the difference?

②: PHP-FPM, is the main process receiving the request and transferring it to the child process, or is the child process receiving the request and processing it separately? How to verify?

③: Why is PHP code rarely pooled in PHP-FPM mode?

④: What are the poor performance of PHP-FPM mode and how to optimize it?

5: Why can't YAC in PHP-FPM mode share memory with CLI mode?

1. How to start a process

PHP-FPM is a multi-process model in which Worker processes are managed by a Master process. The number of processes can be configured via php-fpm.conf. PHP-FPM processes can be divided into dynamic and static modes:

1: Static

Start a specified number of PHP-FPM processes directly, no longer increasing or decreasing; start a fixed number of processes, occupying high memory. However, when user requests fluctuate greatly, the system resources consumed in processing Linux operating system processes are low.

②: Dynamic

Start a certain number of PHP-FPM processes at the beginning, dynamically increase the number of PHP-FPM processes to an upper limit when the number of requests is large, and automatically release the number of idle processes to a lower limit when idle.

Dynamic mode dynamically adjusts the number of processes according to max, min, idle children configuration. When user requests fluctuate or increase instantaneously, a large number of processes are created and destroyed in dynamic mode, resulting in increased Linux load fluctuations. In short, fewer requests, fewer PHP-FPM processes, more requests, more processes. The advantage is that when the request volume is small, the number of processes is small and the memory footprint is small.

3: On demand

In this mode, PHP-FPM's Master does not Fork any child processes, and is purely on-demand.

This pattern is rarely used because it is largely unable to accommodate online traffic of a certain magnitude. Since php-fpm is a short connection, each request will establish a connection first, and the process of establishing a connection will inevitably trigger the execution steps in the above figure. Therefore, the Master process will become busy on a high-traffic system, consuming system CPU resources and not suitable for deployment in a high-traffic environment.

To borrow a picture from the Internet:

There are two points to note,"connection" and "data" arrival. There are connections coming in and then Fork processes, which can also achieve the purpose of child processes inheriting the parent process context, and then the child process processes the user request.

(Refer to PHP documentation for parameters related to dynamic and static process modes.)

What we need to focus on is whether the PHP-FPM model we should choose for our own business is dynamic or static.

Generally speaking, for servers with large memory, setting it static will improve efficiency. Because php-fpm processes are often switched on and off with delays, static effects are better when memory is large enough. The number can also be obtained according to memory/30M. For example, a server with 2GB memory can be set to 50;4GB memory can be set to 100, etc. High-configuration machines choose static, low-configuration machines (save memory) choose dynamic, high-configuration machines with dynamic can not make full use of memory resources and CPU resources, nor can they respond to instantaneous high concurrency in time.

2. How to process and validate requests

PHP-FPM process management is somewhat similar to Nginx process management. When processing requests, the child processes accept user requests preemptively, rather than the main process accepting requests and passing them on to child processes. In essence, PHP-FPM multi-process and Nginx multi-process, after the main process listens to the same port, Fork sub-process achieves the purpose of multiple processes listening to the same port.

All process IO operations in Linux require interaction with the operating system. That is, the system knows all IO operations. This process is often referred to as a "system call." We can solve this problem by starting with system calls. System calls can be viewed using Strace.

How to verify is relatively simple, we can take two ways:

See the logs of the PHP-FPM process. This requires configuring the appropriate PHP-FPM log format;

Since IO data is transitioned from kernel mode to user mode, we can trace system calls with the strace -p command. Track the main process ID and child process ID of PHP-FPM respectively, and then visit Nginx, and Nginx will go to the PHP-FPM process through the fast-cgi protocol to see which process sent the system call.

3. Why not do code join pooling under PHP-FPM?

First, in PHP-FPM mode, a request is destined to have only one lifecycle. That is, PHP-FPM recovers all resources requested from the FPM request, parsing the PHP script, through the FPM's Zend VM allocation execution, and finally through the final processing.

One is to keep developers from caring about recycling resources, so you probably don't care much about network shutdowns, file descriptors shutdowns, and so on. The second is to reduce memory overflow.

If you implement connection pooling in this mode, it also means that the request is over, the connection pool disappears, and you have done nothing.

"PConnect"(persistent link). Persistent links are links that are not released. The problem is that PHP-FPM is a multi-process pattern, and persistent links exist in processes. This means that if a machine has 300 FPM processes, 300 persistent links will be initialized at once. If the machine is expanded rashly due to business activity requirements, it is likely to cause the number of database connections of the business to be directly full.

4. How to optimize performance

First, we should think about what the possible causes of poor performance are. If the performance of an application is poor, we often analyze it from two aspects, one is IO performance and the other is computing performance.

In terms of IO, because it is difficult to pool connections in PHP-FPM mode, network processing under high concurrent services will have disadvantages. Note that I have been talking about PHP-FPM mode, in CLI mode or you can do your own connection pool. However, this connection pool is limited to a single process in CLI mode, and this mode cannot be used to process network requests (such as HTTP requests). Because PHP defaults to single-process mode, FPM and CLI are default single-process, even if CLI can do connection pooling, it is not convenient to do link keepalive (heartbeat detection cannot be done at the same time).

Computationally speaking, PHP is written in C, but it is good if only in terms of computational performance. But the problem is that PHP has to parse PHP script, translate PHP code into Opcode, execute Opcode with Zend virtual machine, and release resources at the end of processing. Going through this process is one of the biggest causes of PHP's slow computational performance.

How to optimize:

For computational performance, use the Zend OPcache extension to cache bytecodes.

For ** IO performance **, use file cache or memcached to reduce the pressure on the network Cache; use Yac to reduce the pressure on the Cache layer; in the same request; reuse links do not use new ones every time; reasonably design log component libraries, optimize Logger to reduce the number of file operations to reduce IO pressure.

There are a few things to note about designing a qualified Logger component:

Do log writing only once per request, instead of doing something like file_put_contents every time someone calls your function.

Compatible with similar errors. In other words, even if a PHP fatal error occurs, you need to be able to log the error before it becomes known. This can be done with the help of PHP class destructors. You can also use the better register_shutdown_function to register a hook that is called back at the end of the PHP request to complete the final logging operation.

5. Why YAC cannot share memory with CLI mode

We know that one of the first macros executed in PHP extension development is PHP_MINIT_FUNCTION. The YAC extension needs to initialize a block of shared memory at PHP-FPM process startup for shared use by various processes. Therefore, the key to sharing is to have the same identity known to all processes.

The initialization process for the YAC extension is:

Let's look at the concrete implementation of create_segments:

The most important is the system ID required to enable shared memory, shared_segment_name, which contains the process ID. This is the main process ID of PHP-FPM. Having the same shared memory ID is the secret of communication between all processes in PHP-FPM mode. And if we wanted to read this shared memory using yac extension via PHP script, we would do this:

In CLI mode, it is impossible to get the shared memory data set in PHP-FPM mode. This is because PHP scripts executed in CLI mode and process IDs are completely different from those executed in PHP-FPM mode.

Thank you for reading, the above is the content of "PHP-FPM multi-process model related knowledge points", after learning this article, I believe that everyone has a deeper understanding of PHP-FPM multi-process model related knowledge points, the specific use of the situation still needs to be verified by practice. Here is, Xiaobian will push more articles related to knowledge points for everyone, welcome to pay attention!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.