When php-fpm is generating a page, will php-fpm exit after the browser is refreshed? -Php Tutorial

When php-fpm is generating a page, will php-fpm exit after the browser is refreshed? I haven't written a blog for a long time, because there is nothing to write.

The reason for this question is that I read an article titled "PHP upgrade", which leads to an analysis of the problem of high system load. After reading it, some of the text triggers my idea and I want to verify it.

Solution: Use tcpdump to capture packets and use strace to obtain system calls

tcpdump port 8080 and port 9000 -s 0 -w temp

8080 is the service port of nginx, and 9000 is the port of the php-fpm service. capture these two ports to see the interaction between the browser, nginx, and php-fpm. After the packet is captured, use wireshark for analysis as follows:

Tcp. port = 46540 or tcp. port = 54352 // the preceding statement is the wireshark filter syntax used to filter packets we are interested in.

Explanation:

54352 indicates the browser port, http-alt indicates nginx, indicates the port for nginx to request php-fpm, and cslistener indicates php-fpm.

2. because all my operations are on one machine, including browser access, all IP addresses are 127.0.0.1

3,

A: The first part in the figure represents the three-way handshake between the browser and nginx.

B: The second part in the figure indicates that the browser requests a URL from nginx.

C: The third part in the figure represents the three-way handshake between nginx and php-fpm.

D: The fourth part in the figure indicates that nginx forwards browser requests to php-fpm.

E: lines 11, 13, and 14 in the fifth part of the figure indicate that the browser closes the connection with nginx. Why is it closed? because I constantly refresh the page. during the second refresh, the browser will close the last request.

Why is it three times instead of four handshakes? Because row 3 is actually sent by combining two packages into one package, this should be considered tcp optimization.

F: Lines 12 and 25 in the fifth part of the figure indicate that nginx tells php-fpm to close the connection from the browser.

G: The sixth part in the figure. the time on the left shows that php-fpm tries to return it to nginx after five seconds? After the page is dyed, nginx directly reset the connection.

Why is it returned in five seconds, because I used sleep (5) in the first line of the php program to simulate long business logic processing.

From the analysis, the conclusion is obvious:

After the browser closes the request, nginx will notify php-fpm, but php-fpm ignores this notification and continues processing until the processing result is sent.

I think there is still room for optimization in php-fpm.

You can check the strace results or verify the above conclusions.