root@d856fd02d2fe:~# ps aux -L
USER  PID LWP %CPU NLWP %MEM VSZ RSS TTY  STAT START TIME COMMAND
root   1  1 0.0 1 0.0 4504 692 "color: #ff0000">1. 什么是线程：线程有时又称轻量级进程(Lightweight Process，LWP)，通常由线程ID、当前指令指针(PC）、寄存器集合和堆栈组成，是进程中的一个实体，是被系统独立调度的基本单位；线程自己不拥有系统资源，只拥有一点儿在运行中必不可少的资源，与同属一个进程的其它线程共享进程所拥有的全部资源。 由于线程之间的相互制约，致使线程在运行中呈现出间断性。线程也有就绪、阻塞和运行三种基本状态。由于进程是资源拥有者，创建、撤消与切换开销过大，在对称多处理机（SMP）上同时运行多个线程（Threads）才是更合适的选择。线程的实体包括程序、数据和线程控制块（Thread Control Block，TCB），TCB包括以下信息：

（1）线程状态；


（2）当线程不运行时，被保存的现场资源；


（3）一组执行堆栈；


（4）存放每个线程的局部变量主存；


（5）访问同一个进程中的主存和其它资源。


但使用多个进程会使得应用程序在出现进程池内的进程崩溃或被攻击的情况下变得更加健壮。
2. 模拟多线程：


<"GET {$_SERVER['PHP_SELF']}");
   sleep(1);//usleep(500)
   fclose($fp);
  }

  $this->log();
 }

 /**
  * 日志记录当前模拟线程运行时间
  *
  * @return void
  */
 private function log()
 {
  $fp = fopen('simulated.thread', 'a');
  fputs($fp, "Log thread {$this->thread} at " . microtime(true) . "(s)\r\n");

  fclose($fp);
 }
}

$thread = new SimulatedThread();
$thread->simulate();
echo "Started to simulate threads...";


探秘汇总：本人通过运行上述脚本后，发现一些可预料但却不是我曾想到的结果
1. PHP-FPM配置项pm.max_children = 5，simulated.thread记录如下：


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)


最新生成的(模拟)线程登记出现在红色标示条目位置是因为进程池的并发连接处理能力上限为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进程池探秘就是小编分享给大家的全部内容了，希望能给大家一个参考，也希望大家多多支持。