一、nginx 和 php-fpm 的关系和分工
nginx 是 web 服务器， php-fpm 是一个 PHPFastCGI 进程管理器，两者遵循 fastcgi 的协议进行通信， nginx 负责静态类似 html 文件的处理， php-fpm 负责 php 脚本语言的执行，这么设计的目的是为了解耦前端 nginx 和后端的 php ，不至于让容易出问题的 php 脚本堵塞整个 nginx 的业务处理，影响用户体验，因为 php 脚本语言的执行是会比较容易出问题的。 nginx 之所以能处理成千上万高并发业务，除其本身的异步非阻塞模式，在与和其他模块的耦合扩展方法也是分不开的，在 nginx 的设计里不能接受的就是阻塞，不过并非完全没有梗，比如说用到的最多的多进程单线程的模式，由于 nginx 日志没有单独的处理进程，如果收集日志时处理不当就会把 worker 进程堵死。
对应nginx+php-fpm的模型结构图如下：
（图 1）
1、nginx 的工作简介（对应图1看）
在接到 php的脚本 请求后， nginx 通过 fastcgi_pass 指令将请求传递给后端 php-fpm 的 worker 进程处理，在此过程中， nginx 做了各种超时机制、缓存机制、 buffer 机制和长连接机制等来保障与后端的 php-fpm 能够良性高效的合作。
在超时机制方面控制 nginx 对后端 php 的等待时间，通过各种 timeout 指令进行控制，例如：
fastcgi_connect_timeout 后端链接时间
fastcgi_send_timeout 数据发送时间，两次成功发送时间差，不是整个发送时间
fastcgi_read_timeout 数据接收时间，两次成功接收时间差，不是整个接收时间
当超时后会返回 504 超时的状态码，在 buffer 机制指令也有很多，例如：
fastcgi_buffer_size 存放 fastcgi 传过来的响应头，一般设置为分页大小
fastcgi_buffers 存放 fastcgi 传过来的相应内容，一般设置分页的倍数，格式例如 8 4k|8k
另外还有一些其它的缓存、长连接机制不做介绍，当设置不合理时也会出现 5XX 错误，nginx的文章介绍写了有很多的，不再做过多的说明。
2、php-fpm 工作介绍（对应图1看）
Php-fpm 是一个 PHPfastcgi 进程管理器，在启动后会有 master 和 worker 两种进程， master 负责接收外部信号和管理 worker 进程， worker 进程是负责干活的，处理 nginx 传过来的任务。
master 进程只有一个，负责监听端口和管理 worker 进程，每次传来任务，与前端的 nginx 建立 3 次握手后放入连接队列，供 worker 进程进行 accept ，当 worker 进程出现错误或执行超时时，负责将 worker 进程重启或者杀掉，是 php-fpm 模型中的大内总管。
Worker 进程是工作进程，每个 worker 进程都独立的执行 php 程序脚本，然后把执行的结果通过 fastcgi 协议交给 nginx ，执行过程中受 master 的管理。在工作中， worker 进程去竞争 accept 管理进程 master 的链接队列， accept 函数将从连接请求队列中获得连接信息，创建新的 socket ，并返回该套接字的 fd ，新创建的 socket 用于服务器与 nginx 的通信，而原来的套接字仍然处于监听状态。
php-fpm 可以配置多个 pool ，所有 pool 由 master 统一管理监听不同端口并分配不同 worker 进程池， worker 进程池支持动态 prefork 同时也支持静态开启，服务器内存较大时建议直接计算后配置静态资源池，可以减少频繁 prefork 进程所带来的开销，提高服务质量，由于进程模型越跑程序耗费越大，因为每个 worker 进程可以配置执行多少个请求后进行重启，对应的池子的指令和执行多少个请求的指令如下：
pm = static | dynamic | ondemand 静态池、服务优先、内存优先
pm.max_children = 256 开启的最大 php 进程数
pm.max_requests = 1024 在执行了 1024 个请求后重启 worker 进程
这也是我们线上服务器的配置，我们线上用的 web 服务的机器是 12 核 cpu 、 16G 内存， nginx 开启 12 个 worker 进程， php 开启 256 个进程，跑起来后每个进程大概占用 30M 内存，也就是（ 256+12 ） *30=8G ，另外还跑了一些配管、监控、统计、日志收集等七七八八的软件，整体业务是比较轻松的，这种静态池的配置大大减少了 prefork 进程带来的开销，RT时间100ms以内的占到85%（这个与程序写的如何有关），运行一段时间后的开销截图如下：
二、此模型结构常见的5XX服务器端错误及优化（对应图1看）
1、nginx日志里 产生 502 错误
第一种情况， php-fpm的worker进程 执行 php 程序脚本时，超过了配置的最长执行时间， master 进程将 worker 进程杀掉，直接返回 502 。
返回 502 后 nginx 对应的 error 日志是 104: Connection reset by peer
对应的 php 执行时间的配置如下，一些版本中 php-fpm 的配置会覆盖 php.ini 的配置，使 php.ini 的配置不起作用：
php.ini 中默认 30s ： max_execution_time =
php-fpm 中： request_terminate_timeout =
第二种情况， 连接请求数（ accpet 之前）超出了端口所能监听的 tcp 连接的最大值（ backlog 的值），进不了 fpm 等待 accept 的链接队列，直接返回 502 ，这里可能会产生 tcp 重传；
返回 502 后 nginx 对应的 error 日志是 111: Connection refused
backlog 的值是半连接和全连接的总和，他的存在也有短时间缓冲解耦 nginx 请求与 fpm 处理的作用，半连接指收到了 syn 请求， 3 次握手尚未建立，全连接指的是 3 次握手已经成功，不过尚未被 accpet 的请求， fpm 里面有调节的参数，如果 fpm 的参数设置为 -1 ，则默认走的是系统内核参数 net.core.somaxconn 的设置值，如果不设置可以在 /proc/sys/net/core/somaxconn 里查看，默认值是 128 ，所以在连接请求较高的业务里要增大这个值。
减少避免 502 报错优化建议
502主要从php-fpm的配置方考虑，根据服务器情况， 适量增大 php-fpm 的工作进程数，适当增加 php 的执行时间，适当增加 backlog 值 。
php 的工作进程数也不是越大越好，这种进程模型运行时间长了占的内存会增大，一般一个 php 进程是占到 30M 左右的内存，开多少合适自己算吧， nginx 的 worker 进程一般也能跑到 30M 的内存，综合计算一下； php 的执行时间可以根据你的服务标准来设定，超过服务时间浏览器返回的是 502 错误，这个按照实际的情况处理吧，反正我是觉得执行的慢有返回结果总比直接返回 502 错误的强；至于 backlog 值，当程序写的比较好时，建议设置其数量为 php 工作进程的 1 到 2 倍。
2、nginx日志里 产生 504 错误
第一种情况，php 的 worker 进程池处理慢，无法尽快处理等待 accept 的链接队列，导致 3 次握手后的链接队列长时间没有被 accept ， nginx 链接等待超时；
返回 504 后 nginx 对应的 error 日志是 110: Connection timed out
第二种情况，后端php-fpm执行脚本的时间太长，超过了nginx配置的超时机制，这个时候也是会报出504错误的。
减少避免504报错的优化建议
504主要从nginx的配置方考虑，根据业务情况配置好超时的各种机制，包含但不限于下属参数：
fastcgi_connect_timeout
fastcgi_send_timeout
fastcgi_read_timeout
。。。。。。。。
另外： 在配置过程中，比如遇到大并发或者是特殊业务的场景，不合理的fd、buffer等设置也会带来5XX错误，比如说大并发连接的业务要增大系统和单个程序的fd数量，如果是上传业务要增大头buffer等，这些要视情况而做优化，正所谓道法自然，术变万千，要以不变应万变。
关注微信公众号：PHP技术大全
PHPer升级为大神并不难！
