PHP优化杂烩

pool

一个让人沮丧的消息是绝大多数 PHP 程序员都忽视了池的价值。这里所说的池可不是指数据库连接池之类的东西，而是指进程池，PHP 允许同时启动多个池，每个池使用不同的配置，各个池之间尊重彼此的主权领土完整，互不干涉内政。

pool

有什么好处呢？默认情况下，PHP 只启用了一个池，所有请求均在这个池中执行。一旦某些请求出现拥堵之类的情况，那么很可能会连累整个池出现火烧赤壁的结局；如果启用多个池，那么可以把请 求分门别类放到不同的池中执行，此时如果某些请求出现拥堵之类的情况，那么只会影响自己所在的池，从而控制故障的波及范围。

listen

虽然 Nginx 和 PHP 可以部署在不同的服务器上，但是实际应用中，多数人都习惯把它们部署在同一台服务器上，如此就有两个选择：一个是 TCP，另一个是 Unix Socket。

listen

和 TCP 比较，Unix Socket 省略了一些诸如 TCP 三次握手之类的环节，所以相对更高效，不过需要注意的是，在使用 Unix Socket 时，因为没有 TCP 对应的可靠性保证机制，所以最好把 backlog 和 somaxconn 设置大些，否则面对高并发时会不稳定。

pm

进程管理有动态和静态之分。动态模式一般先启动少量进程，再按照请求数的多少实时调整进程数。如此的优点很明显：节省资源；当然它的缺点也很明显： 一旦出现高并发请求，系统将不得不忙着 FORK 新进程，必然会影响性能。相对应的，静态模式一次性 FORK 足量的进程，之后不管请求量如何均保持不变。和动态模式相比，静态模式虽然消耗了更多的资源，但是面对高并发请求，它不需要执行高昂的 FORK。

pm

对大流量网站而言，除非服务器资源紧张，否则静态模式无疑是最佳选择。

pm.max_children

启动多少个 PHP 进程合适？在你给出自己的答案之前，不妨看看下面的文章：

• php-fpm的max_chindren的一些误区
• Should PHP Workers Always Equal Number Of CPUs

一个 CPU 在某一个时刻只能处理一个请求。当请求数大于 CPU 个数时，CPU 会划分时间片，轮流执行各个请求，既然涉及多个任务的调度，那么上下文切换必然会消耗一部分性能，从这个意义上讲，进程数应该等于 CPU 个数，如此一来每个进程都对应一个专属的 CPU，可以把上下文切换损失的效率降到最低。不过这个结论仅在请求是 CPU 密集型时才是正确的，而对于一般的 Web 请求而言，多半是 IO 密集型的，此时这个结论就值得商榷了，因为数据库查询等 IO 的存在，必然会导致 CPU 有相当一部分时间处于 WAIT 状态，也就是被浪费的状态。此时如果进程数多于 CPU 个数的话，那么当发生 IO 时，CPU 就有机会切换到别的请求继续执行，虽然这会带来一定上下文切换的开销，但是总比卡在 WAIT 状态好多了。

那多少合适呢？要理清这个问题，我们除了要关注 CPU 之外，还要关注内存情况：

PHP Memory

如上所示 top 命令的结果中和内存相关的列分别是 VIRT，RES，SHR。其中 VIRT 表示的是内存占用的理论值，通常不用在意它，RES 表示的是内存占用的实际值，虽然 RES 看上去很大，但是包含着共享内存，也就是 SHR 显示的值，所以单个 PHP 进程实际独立占用的内存大小等于「RES – SHR」，一般就是 10M 上下。以此推算，理论上 1G 内存能支撑大概一百个 PHP 进程，10G 内存能大概支撑一千个 PHP 进程。当然并不能粗暴认为越多越好，最好结合 PHP 的 status 接口，通过监控活跃连接数的数量来调整。

说明：关于 Web 并发模型方面的知识建议参考范凯的「Web并发模型粗浅探讨」。