WebService之nginx+

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

随着php脚本语言的流行，目前大部分webserice服务都在使用nginx+(php-fpm)的结构。了解了它的工作流程后，你就可以想办法从各个方面进行调整、优化和故障排除。这个模式从以下几点来总结。

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

NGX是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)

nginx收到php的脚本请求后，通过fastcgi_pass指令将请求传递给后端php-fpm的worker进程。在这个过程中，nginx做了各种超时机制、缓存机制、缓冲机制、长连接机制，保证与后端php-fpm的良性高效协作。

在超时机制方面，nginx对于后端php的等待时间是由各种超时指令控制的，比如:

fastgi_connect_timeout后端链接时间

fastcgi_send_timeout数据发送时间，即两次成功发送之间的时间差，并不是整个发送时间。

fastcgi_read_timeout数据的接收时间，即两次成功接收的时间差，并不是整个接收时间。

当它超时时，它将返回504超时的状态代码。缓冲机制中也有许多指令，例如:

fastcgi_buffer_size存储fastcgi发送的响应头，一般设置为页面大小。

fastcgi_buffers存储fastcgi发送的对应内容，一般设置分页倍数，例如84k|8k。

此外，还有一些其他的缓存和长连接机制没有介绍。当设置不合理时，会出现5XX错误。nginx的文章里有很多介绍，不需要我过多解释。

2.php-fpm简介(见图1)

Php-fpm是一个PHPfastcgi进程管理器。启动后，将有两个进程，主进程和工作进程。master负责接收外部信号和管理worker进程，worker进程负责工作和处理nginx发送的任务。

只有一个主进程，负责监控端口和管理工作进程。每次发送任务，在前端与nginx握手后放入连接队列，供工作进程接受。当工作进程出错或超时执行时，它负责重新启动或终止工作进程。它是php-fpm模型中的管理器。

工作进程是一个工作进程。每个worker进程独立执行php脚本，然后通过fastcgi协议将执行结果交给nginx。执行过程由master管理。在工作中，工作进程竞争接受管理进程主进程的链接队列。accept函数将从连接请求队列中获取连接信息，创建一个新的套接字，并返回套接字的fd。新创建的套接字用于服务器和nginx之间的通信，而原来的套接字仍处于监听状态。

Php-fpm可以配置多个池。所有池都由master管理，以监视不同的端口并分配不同的工作进程池。工作进程池支持动态预工作和静态启动。当服务器内存较大时，建议直接计算后配置静态资源池，这样可以减少频繁的prefork进程带来的开销，提高服务质量。随着流程模型运行得越来越快，程序的成本也越来越高，因为每个工作进程都可以配置在重新启动之前执行多少个请求。相应的池指令和关于执行多少请求的指令如下:

Pm=static|dynamic|ondemand静态池，服务优先，内存优先

打开的php进程的最大数量

Pm.max_requests=1024在执行1024个请求后重新启动工作进程。

这也是我们在线服务器的配置。我们在线web服务的机器是一个12核cpu和12G内存。nginx启动12个工作进程，php启动256个进程。运行后每个进程占用30M左右内存，即(256+12)*30=8G。此外，一些软件如管道、监控、统计、日志收集等。正在运行。整体业务比较轻松。这种静态池配置大大降低了prefork过程带来的开销，100ms以内的RT时间占90%以上(这和程序怎么写有关)。运行一段时间后的开销截图如下:

二。该模型结构常见的5XX服务器端错误及其优化(见图1)

1.nginx日志中出现502错误。

第一种情况，php-fpm的工作进程执行php脚本时，超过配置的最大执行时间，主进程杀死工作进程，直接返回502。

返回502后nginx对应的错误日志是104:连接被对等体重置。

对应的php执行时间的配置如下。在某些版本中，php-fpm的配置会覆盖php.ini的配置，使php.ini的配置无效:

php.ini中默认30秒:max_execution_time=

在php-fpm中:request_terminate_timeout=

第二种情况，连接请求数(accpet之前)超过了端口所能监控的tcp连接数的最大值(backlog的值)，所以进不去fpm等待接受的链接队列，直接返回502，可能导致tcp重传；

返回502后，nginx对应的错误日志是111:连接被拒绝。

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值，在程序写得好的情况下，建议设置为phpworkerprocess的1到2倍。

2.nginx日志中出现504错误。

第一种情况，php的worker进程池对等待接受的链接队列处理速度慢，导致3次握手后的链接队列长时间不被接受，nginx链接等待时间超时；

返回504后nginx对应的错误日志是110:连接超时。

第二种情况，后端php-fpm执行脚本的时间太长，超过了nginx配置的超时机制。此时，还会报告一个504错误。

第三种情况，客户端的网络极差。php处理完请求交给nginx后，nginx未能在超时期限内向用户吐出所有内容。这时也会超时，只有504而不是502。

减少优化建议以避免504错误

504主要考虑nginx的配置器，根据业务情况配置各种超时机制，包括但不限于从属参数:

fastcgi_连接_超时

fastcgi_发送_超时

fastcgi_read_timeout

。。。。。。。。

另外:在配置的过程中，比如大并发或者特殊业务的情况下，fd、buffer等不合理的设置也会带来5XX错误。比如大并发连接业务要增加系统和单个程序的fd数，上传业务要增加头缓冲。这些要根据情况进行优化。正所谓道法自然，技巧万千，要以不变应万变。

自建个人原创站运营网吧俱乐部(www.net-add.com)，新的博文会在网吧俱乐部更新。欢迎浏览。