讲 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 接口，通过监控活跃连接数的数量来调整。