先说结论：瓶颈在高并发下CPU的有效利用率不可思议的低，低于5%；而此时cpu使用率已经100%

再来解释原因：

发展到这个阶段了，所有成熟的语言一般都有manager和worker的细分工

你看下fpm的进程，也是有master（manager）和pool（worker）进程，一般会有多个worker进程。

fpm本身性能几乎是神一样的队友，但是因为php的简单性，没法做神级actor，actor是通过系统内核提供的事件模型来有效提升cpu有效利用率的机制。常见系统内核提供的高效率事件模型有 epoll kqueue evport iocp等等。

既然做不出了actor，又不能破坏php的简单，只能用多开进程，每个进程单线程。

以下原因导致cpu真实利用率在高并发下极低：

1，线程是操作系统调度的最小单位，这句对于理解低效原因很重要。

2，系统切换运行线程需要较大开销

3，web应用典型场景就是io多耗时较长，io就不解释了，能看到或者问到这个问题的，多少有点概念吧。

php因为本身没有actor，所以所有io都是去同步等待，然后问题来了：

高并发下，系统每切一个线程，发现每个线程都在等待io，什么事都做不了，系统只能花费95%的工作切fpm的worker线程玩，而5%的工作是真正处理worker内php代码。就是高并发+io等待下cpu空转。

那空闲的时候fpm是怎么做的呢？因为没有运行php脚本，所以空闲的时候，fpm- worker明确告诉操作系统：我目前不需要调度，性能很高。

如果fpm能做actor情况则会明显好转：

等待的worker线程，我直接告诉操作系统别去调度，只有非等待的进程才让操作系统去调度并分配cpu等资源，这样空转就不会发生。

问题在于，php脚本本身无法利用事件模型，无法告诉主管（fpm）自己是在摸鱼（等待io）还是在真实工作，而大老板（操作系统）也无法知道php是在摸鱼，只能挨个去检查；最后php说：我不是在摸鱼而是在努力等待等快递进行下一步工作。