为何PHP FPM的pm-dynamic模式存在大量性能开销？

• 进程初始化的叠加成本
  动态模式下，当现有空闲进程不足以处理请求时，FPM需要新建子进程。这个过程包含PHP解释器初始化、加载Drupal核心依赖（含Memcached扩展、模块初始化逻辑）、建立Memcached连接（即便启用缓存，新进程首次连接仍有握手开销），这些操作会直接附加到当前请求的响应时间中，导致单次请求被拉长至数百毫秒。而静态模式下所有进程提前启动并完成预热，请求到来时直接使用就绪进程，无这部分初始化开销。

• 请求队列与调度延迟
  动态模式下若突发流量超出当前空闲进程数，新请求会进入队列等待新进程启动。排队时间加上进程启动时间，会让终端用户感知的响应时间大幅波动——低峰时可能有空闲进程，响应接近静态模式的150ms；高峰或突发请求时，排队+进程启动的耗时会把响应拉至600ms以上。静态模式下进程数量固定且充足，请求无需排队，响应时间保持稳定。

• 资源竞争加剧启动耗时
  新建进程需要系统分配内存、CPU时间片，若服务器已有一定负载，新进程的创建会与现有业务进程争抢资源，进一步拉长启动时间。静态模式的进程是在服务器低负载阶段提前启动的，初始化过程不会和业务请求竞争资源。

• Drupal框架特性放大了开销
  Drupal属于重型框架，即便启用Memcached缓存，新进程首次启动时仍需加载大量类文件、初始化钩子系统、读取配置（即便配置已缓存，进程启动时的加载逻辑依然存在）。这些操作在静态模式下提前完成，而动态模式下每新建一个进程都要重复执行，这部分开销会直接体现在终端用户的请求响应中。

内容的提问来源于stack exchange，提问作者JM John