WebService之nginx+(php-fpm)结构模型剖析及优化

一、nginx和php-fpm的关系和分工

  对应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、12G内存，nginx开启12个worker进程，php开启256个进程，跑起来后每个进程大概占用30M内存，也就是（256+12）*30=8G ，另外还跑了一些配管、监控、统计、日志收集等七七八八的软件，整体业务是比较轻松的，这种静态池的配置大大减少了prefork进程带来的开销，RT时间100ms以内的占到90%以上（这个与程序写的如何有关），运行一段时间后的开销截图如下：

二、此模型结构常见的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，所以在连接请求较高的业务里要增大这个值。

    第三种情况，网络卡时，客户端断开连接，nginx处显示499，然后php检查到前端nginx产生abort后，又master结束此条任务的继而产生502，一般此种情况的报警，先是499，过会儿变成502，再过一会变成504.

• 减少避免502报错优化建议

502主要从php-fpm的配置方考虑，根据服务器情况，适量增大php-fpm的工作进程数，适当增加php的执行时间，适当增加backlog值。
    php的工作进程数也不是越大越好，这种进程模型运行时间长了占的内存会增大，一般一个php进程是占到30M左右的内存，开多少合适自己算吧，nginx的worker进程一般也能跑到30M的内存，综合计算一下；php的执行时间可以根据你的服务标准来设定，超过服务时间浏览器返回的是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错误的。

    第三种情况，客户端的网络及其差，php将请求处理完交给nginx后，nginx没能在超时时间内将内容全部吐给用户，这时也会超时，只有504而没有502。

• 减少避免504报错的优化建议

   

    504主要从nginx的配置方考虑，根据业务情况配置好超时的各种机制，包含但不限于下属参数：

    fastcgi_connect_timeout

    fastcgi_send_timeout 

    fastcgi_read_timeout 

    ...... 
 

    另外：在配置过程中，比如遇到大并发或者是特殊业务的场景，不合理的fd、buffer等设置也会带来5XX错误，比如说大并发连接的业务要增大系统和单个程序的fd数量，如果是上传业务要增大头buffer等，这些要视情况而做优化，正所谓道法自然，术变万千，要以不变应万变。