基于PHP-FPM进程池探秘

时间：2017-10-26

最新生成的(模拟)线程登记出现在红色标示条目位置是因为进程池的并发连接处理能力上限为5，因此它只可能出现在第六条以后的位置。

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)

有意思的是绿色条目代表的(模拟)线程和红色条目代表的(模拟)线程的登记时间是一样的，说明两个(模拟)线程是并发执行的。

2. PHP-FPM配置项pm.max_children = 10，simulated.thread记录如下：

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)

由于服务端并发连接处理能力上限达到10，因此最新生成的(模拟)线程登记可出现在任何位置。

3. 执行usleep(500)延迟，simulated.thread记录如下：

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)

可见日志记录顺序与(模拟)线程生成的顺序一致。usleep延迟的基本单位是微妙(us， 1 s = 1000000 us)。

从以上的记录可以看出：

1）这些(模拟)线程是第一次请求执行脚本后就自动生成的，一个(模拟)线程紧接着创建了另一个(模拟)线程；

2）这些(模拟)线程中有的是在同一个子进程空间中产生并运行的；

3）前后相邻(模拟)线程生成时间间隔很小，几乎是同时产生，或后一个(模拟)线程在前一个(模拟)线程尚未执行结束并退出之前产生；

4）多个(模拟)线程之间可以并发执行。

所以，上述模拟多线程并发的实现是成功的。PHP-FPM进程池中同一个子进程可先后处理多个连接请求，但同一时间只能处理一个连接请求，未处理连接请求将进入队列等待处理。换句话，同一个子进程不具有并发处理连接请求的能力。

PHP-FPM Pool配置：它允许定义多个池，每个池可定义不同的配置项。以下只是列举了我在探秘过程中还关注过的其他部分配置项

1、 listen：The address on which to accept FastCGI requests.它支持TCP Socket和unix socket两种通讯协议。可设置listen = [::]:9000。

2、listen.allowed_clients：List of addresses (IPv4/IPv6) of FastCGI clients which are allowed to connect. 该配置项为逗号分隔的列表，如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. 该配置项设置FPM管理进程池的方式，包括static、dynamic、ondemand三种。

4、pm.max_requests：The number of requests each child process should execute before respawning. This can be useful to work around memory leaks in 3rd party libraries.设置每个子进程处理请求数的上限，对于处理第三方库中的内存泄漏很有用。

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

以上这篇基于PHP-FPM进程池探秘就是小编分享给大家的全部内容了，希望能给大家一个参考，也希望大家多多支持。

共2页:

2/2下一篇

上一篇：PHP实现统计所有字符在字符串中出现次数的方法 下一篇：PHP-X系列教程之内置函数的使用示例

基于PHP-FPM进程池探秘

相关文章

最新文章