PHP-FPM process pool probing, php-fpm pool probing

PHP-FPM process pool probing, php-fpm pool probing

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 Methods: Simulate multi-thread concurrent execution

1.What is threadA 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) on-site resources saved when the thread is not running; (3) a group of execution stacks; (4) primary storage of 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:

1 <? Php 2/*** PHP only supports multi-process and does not support multithreading. 4*5 * The PHP-FPM runs multiple sub-processes in the process pool to process all connections concurrently, 6 * the same sub-process can process multiple connection requests successively, however, at the same time, only one connection request can be processed at a time. Unprocessed connection requests will enter the queue waiting for processing 8*9 */10 11 class SimulatedThread12 {13 // simulate thread 14 private $ thread; 15 16 // host name 17 private $ host = 'tcp: // 172.17.0.5 '; 18 19 // port number 20 private $ port = 80; 21 22 public function _ construct () 23 {24 // use the current time to number the thread 25 $ this-> thread = microtime (true ); 26} 27 28/** 29 * send a new HTTP connection request to the local machine through socket. 30 * currently, the simulated thread is both a server and It is simulated on the client 31*32 * after the current (Program) sub-process sleep (1) will be delayed for 1 s to continue execution, but the connection held by the sub-process will continue to be valid, 33 * unable to process new connection requests, so this approach will reduce the process pool's ability to process concurrent connection requests. 34 * similar to latency processing, there are also time_nanosleep (), time_sleep_until () and usleep (). 35 * and sleep (1) is not secure. nginx may still encounter the following error: 36 * "epoll_wait () reported that client prematurely closed connection, 37 * so upstream connection is closed too while connecting to upstream "38*39 * @ return void40 */41 public function simulate () 42 {43 $ run = $ _ GET ['run']? 0; 44 if ($ run ++ <9) {// simulate up to 10 threads 45 $ fp = fsockopen ($ this-> host, $ this-> port ); 46 fputs ($ fp, "GET {$ _ SERVER ['php _ SELF ']}? Run = {$ run} \ r \ n "); 47 sleep (1); // usleep (500) 48 fclose ($ fp ); 49} 50 51 $ this-> log (); 52} 53 54/** 55 * log record current simulated thread running time 56*57 * @ return void58 */59 private function log () 60 {61 $ fp = fopen ('simulated. thread ', 'A'); 62 fputs ($ fp, "Log thread {$ this-> thread} ". microtime (true ). "(s) \ r \ n"); 63 64 fclose ($ fp); 65} 66} 67 68 $ thread = new SimulatedThread (); 69 $ thread-> simulate (); 70 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.(Simulation)The thread then creates another(Simulation)Thread;

2) These(Simulation) Some threads are generated and run in the same sub-process space;

3) The generation interval between adjacent (simulated) threads is very small, almost simultaneously, orThe next (simulated) thread is generated before the previous (simulated) thread is executed and exited.;

4)Concurrent execution can be performed between 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 waiting for processing. In other words,The same sub-process does not have the ability to concurrently process connection requests.

 

PHP-FPM Pool Configuration: Multiple pools can be defined, and different configuration items can be defined for each pool. The following lists some other configuration items that I have followed during the quest process.