Based on PHP-FPM process pool probing, PHP-FPM process pool exploring

Based on PHP-FPM process pool probing, PHP-FPM process pool exploring

PHP supports multi-process rather than multi-thread; PHP-FPM runs multiple sub-processes in the process pool to process all connection requests concurrently. View the PHP-FPM process pool (pm. start_servers = 2) status through ps as follows:

root@d856fd02d2fe:~# ps aux -LUSER  PID LWP %CPU NLWP %MEM VSZ RSS TTY  STAT START TIME COMMANDroot   1  1 0.0 1 0.0 4504 692 ?  Ss 13:10 0:00 /bin/sh /usr/local/php/bin/php-fpm startroot   7  7 0.0 1 0.4 176076 19304 ?  Ss 13:10 0:00 php-fpm: master process (/usr/local/php/etc/php-fpm.conf)www-data  8  8 0.0 1 0.2 176076 8132 ?  S 13:10 0:00 php-fpm: pool wwwwww-data  9  9 0.0 1 0.2 176076 8132 ?  S 13:10 0:00 php-fpm: pool wwwroot  10 10 0.0 1 0.0 18376 3476 ?  Ss 14:11 0:00 bashroot  66 66 0.0 1 0.0 34420 2920 ?  R+ 15:13 0:00 ps aux -L

From the list, we can see that there are two sub-process PID 8 and PID 9 in the process pool www. Note: NLWP refers to the number of lightweight processes, that is, the number of threads.

What is PHP-FPM (FastCGI Process Manager? The PHP-FPM provides a process management approach for the PHP-CGI, which can effectively control the memory and process, can smoothly reload the PHP configuration, its master process is resident memory. FastCGI is a language-independent, scalable CGI open extension. Its main behavior is to keep the CGI interpreter process in memory for a longer time, instead of fork-and-execute, therefore, high performance is achieved. FastCGI supports distributed deployment and can be deployed on multiple hosts other than WEB servers.

Exploring Method: Simulate concurrent multi-thread execution

1. What is a thread:A thread is also called a Lightweight Process (LWP). It is usually composed of a thread ID, a PC, a register set, and a stack. It is an entity in a Process, it is the basic unit for independent scheduling by the system. threads do not own system resources, but only have a little necessary resources in the running process, all resources owned by the process are shared with other threads of the same process. Due to mutual constraints between threads, the threads are intermittently running. The thread also has three basic states: Ready, blocked, and running. Because a process is the resource owner and overhead of creation, undo, and switching is too large, it is more appropriate to run multiple Threads simultaneously on the symmetric multi-processor (SMP. The Thread entity includes the program, data, and Thread Control Block (TCB). TCB includes the following information:

(1) thread status;

(2) stored on-site resources when the thread is not running;

(3) A group of execution stacks;

(4) Stores local variables of each thread;

(5) access the primary memory and other resources in the same process.

However, multiple processes make the application more robust when the process in the process pool crashes or is attacked.

2. Simulate multithreading:

<? Php/*** PHP only supports multi-process and does not support multithreading. ** The PHP-FPM runs multiple sub-processes in the process pool to concurrently process all connections. * The same sub-process can process multiple connection requests successively, but at the same time * only one connection request can be processed, unprocessed connection requests will enter the queue waiting for processing **/class SimulatedThread {// simulation thread private $ thread; // host name private $ host = 'tcp: // 172.17.0.5 '; // port number private $ port = 80; public function _ construct () {// use the current time to number the thread $ this-> thread = microtime (true );} /*** send a new HTTP connection request to the local machine through socket. * The current simulated thread is both a server and a simulated client. ** the current (Program) sub-process sleep (1) the execution will be delayed by 1 s, but the connection held by the instance will continue to be valid, * cannot be processed New connection requests, so this approach will reduce the process pool's ability to process concurrent connection requests, * similar to latency processing, such as time_nanosleep (), time_sleep_until (), and usleep (). * In addition, sleep (1) is not secure. nginx may still encounter the following error: * "epoll_wait () reported that client prematurely closed connection, * so upstream connection is closed too while connecting to upstream "** @ return void */public function simulate () {$ run = $ _ GET ['run']? 0; if ($ run ++ <9) {// simulate a maximum of 10 threads $ fp = fsockopen ($ this-> host, $ this-> port ); fputs ($ fp, "GET {$ _ SERVER ['php _ SELF ']}? Run = {$ run} \ r \ n "); sleep (1); // usleep (500) fclose ($ fp );} $ this-> log ();}/*** log records the current simulated thread running time ** @ return void */private function log () {$ fp = fopen ('simulated. thread ', 'A'); fputs ($ fp, "Log thread {$ this-> thread} ". microtime (true ). "(s) \ r \ n"); fclose ($ fp) ;}$ thread = new SimulatedThread (); $ thread-> simulate (); echo "Started to simulate threads... ";

Summary: after running the above script, I found some predictable results that I did not think.

1. PHP-FPM configuration item pm. max_children = 5, simulated. thread record as follows:

Log thread 1508054181.4236 at 1508054182.4244(s)Log thread 1508054181.4248 at 1508054182.4254(s)Log thread 1508054181.426 at 1508054182.428(s)Log thread 1508054181.6095 at 1508054182.6104(s)Log thread 1508054182.4254 at 1508054183.4262(s)Log thread 1508054183.4272 at 1508054183.4272(s)Log thread 1508054182.4269 at 1508054183.4275(s)Log thread 1508054182.4289 at 1508054183.43(s)Log thread 1508054182.6085 at 1508054183.6091(s)Log thread 1508054182.611 at 1508054183.6118(s)

The newly generated (simulated) thread Registration appears at the red mark entry location because the maximum concurrent connection processing capacity of the Process pool is 5, so it may only appear after the sixth.

Log thread 1508058075.042 at 1508058076.0428(s)Log thread 1508058075.0432 at 1508058076.0439(s)Log thread 1508058075.0443 at 1508058076.045(s)Log thread 1508058075.6623 at 1508058076.6634(s)Log thread 1508058076.0447 at 1508058077.0455(s)Log thread 1508058076.046 at 1508058077.0466(s)Log thread 1508058077.0465 at 1508058077.0466(s)Log thread 1508058076.0469 at 1508058077.0474(s)Log thread 1508058076.6647 at 1508058077.6659(s)Log thread 1508058076.6664 at 1508058077.6671(s)

Interestingly, the registration time of the green (simulated) thread and the red (simulated) thread is the same, indicating that the two (simulated) threads are concurrently executed.

2. PHP-FPM configuration item pm. max_children = 10, simulated. thread record as follows:

Log thread 1508061169.7956 at 1508061170.7963(s)Log thread 1508061169.7966 at 1508061170.7976(s)Log thread 1508061169.7978 at 1508061170.7988(s)Log thread 1508061170.2896 at 1508061171.2901(s)Log thread 1508061170.7972 at 1508061171.7978(s)Log thread 1508061171.7984 at 1508061171.7985(s)Log thread 1508061170.7982 at 1508061171.7986(s)Log thread 1508061170.7994 at 1508061171.8(s)Log thread 1508061171.2907 at 1508061172.2912(s)Log thread 1508061171.2912 at 1508061172.2915(s)

The maximum number of concurrent connection processing capabilities on the server reaches 10, so the newly generated (simulated) thread registration can appear anywhere.

3. Execution of usleep (500) delay. The simulated. thread record is as follows:

Log thread 1508059270.3195 at 1508059270.3206(s)Log thread 1508059270.3208 at 1508059270.3219(s)Log thread 1508059270.322 at 1508059270.323(s)Log thread 1508059270.323 at 1508059270.324(s)Log thread 1508059270.3244 at 1508059270.3261(s)Log thread 1508059270.3256 at 1508059270.3271(s)Log thread 1508059270.3275 at 1508059270.3286(s)Log thread 1508059270.3288 at 1508059270.3299(s)Log thread 1508059270.3299 at 1508059270.331(s)Log thread 1508059270.3313 at 1508059270.3314(s)

It can be seen that the log record sequence is consistent with the (simulated) thread generation sequence. The basic unit of usleep latency is subtle (us, 1 s = 1000000 us ).

From the above records, we can see that:

1) These (simulated) threads are automatically generated after the first request to execute the script. One (simulated) thread is followed by another (simulated) thread;

2) Some of these (simulated) threads are generated and run in the same sub-process space;

3) The generation interval of adjacent (simulated) threads is very small, almost at the same time, or the last (simulated) thread is generated before the previous (simulated) thread has not been executed and exited;

4) Concurrent execution can be performed among multiple (simulated) threads.

Therefore, the above multi-thread concurrency simulation is successful. The same sub-process in the PHP-FPM process pool can process multiple connection requests, but only one connection request can be processed at a time, unhandled connection requests will enter the queue for processing. In other words, the same sub-process does not have the ability to concurrently process connection requests.

PHP-FPM Pool configuration: it allows you to define multiple pools, each of which can define different configurations. The following lists some other configuration items that I have followed during the quest process.

1. listen: The address on which to accept FastCGI requests. It supports TCP Socket and unix socket communication protocols. You can set listen = [:]: 9000.

2. listen. allowed_clients: List of addresses (IPv4/IPv6) of FastCGI clients which are allowed to connect. This configuration item is a comma-separated List, such as listen. allowed_clients = 127.0.0.1, 172.17.0.5.

3. pm: Choose how the process manager will control the number of child processes. This configuration item sets the FPM method for managing the process pool, including static, dynamic, and ondemand.

4. pm. max_requests: The number of requests each child process shoshould execute before respawning. this can be useful to work around memory leaks in 3rd party libraries. setting the maximum number of requests processed by each sub-process is useful for processing memory leaks in a third-party library.

5. pm. status_path: The URI to view the FPM status page.

The above based on the PHP-FPM process pool exploration is small make up to share with you all the content, hope to give you a reference, also hope that you can support a lot of help house.