502,504 在超时场景下很容易被混同,辨别起来有肯定难度;
499 产生的起因往往也会和 504 会有外在关联。
注:本文为间断测试,所以批改 nginx 或 php-fpm 配置后,记得重启
根本环境(LNMP):
nginx 配置
fastcgi_connect_timeout 5; # nginx 连贯 fastcgi 的超时工夫
fastcgi_send_timeout 10; #nginx 往 fastcgi 发送参数的超时工夫
fastcgi_read_timeout 10; #nginx 从 fastcig 获取数据的超时工夫
php-fpm 配置
request_terminate_timeout = 30 ; 一次申请的最长执行工夫
PHP 脚本:
nginx 的 webroot 创立 codetest.php 文件,通过拜访localhost/codetest.php
复现 http 响应 code;
499 复现
php-fpm.conf:
request_terminate_timeout=30
nginx:
fastcgi_read_timeout 5;
代码:
sleep(15);
echo ‘hello world’;
499 报错信息:Client Closed Request;即 客户端被动断开连接。
指一次 http 申请在客户端指定的工夫内没有返回响应,此时,客户端会被动断开连接,此时表象为客户端无响应返回;
此状态码在浏览器申请时简直不可见,因为浏览器默认超时工夫很长 ;
多见于业务架构中的服务模块之间的调用。
复现路径:
在 linux 终端应用 curl 命令申请,-m 示意超时工夫,单位秒
curl -i -m 3 http://127.0.0.1/codetest.php
返回:
Operation timed out after 3004 milliseconds with 0 bytes received
此时,nginx 的 access_log 会呈现如下信息:"HEAD /codetest.php HTTP/1.1" 499
502 复现
502,Bad Gateway,网关谬误,它往往示意网关从上游服务器中接管到的响应是有效的。
先来理解一下网关是什么含意
从宏观定义上来说只有是连贯两个不同网络设备的都能够叫网关,具体到 Http 申请这里,网关就是指是转发其余服务器通信数据的服务器,于本文而言,Nginx 就是网关。
502 并不是指网关自身出了问题,而是从上游接管响应出了问题,比方因为上游服务本身超时导致不能产生响应数据,或者上游不依照协定约定来返回数据导致网关不能失常解析。
复现门路 -1
敞开 php-fpm 过程,返回 502。
这个比拟容易了解,参照下面的定义,因为 php-fpm 过程敞开,nginx 连贯不上 php-fpm,即 nginx 不能收从下层接管到响应数据。
nginx 谬误日志相似如下内容:
connect() to unix:xxxx/php-cgi.sock failed (2: No such file or directory) while connecting to upstream
复现门路 -2
启动 php-fpm 过程,批改 php-fpm.conf 的 request_terminate_timeout 和 php 代码的 sleep 工夫来复现。
php 代码:
`sleep(15);
echo ‘hello world’;`
php-fpm.conf
request_terminate_timeout=5
nginx
fastcgi_read_timeout 10;
php-fpm.conf 设置的最大执行工夫是 5s,然而 php 脚本须要的执行工夫大于 15s,所以 php-fpm 过程执行 5s 时就回退出,此时 php 脚本没有失常执行实现,所以返回给网关 Nginx 的数据异样,于是导致 502。
php-fpm 谬误日志如下:
script ‘/webroot/codetest.php’ (request: “GET /codetest.php”) execution timed out (5.161544 sec), terminating
nginx 谬误日志
recv() failed (104: Connection reset by peer) while reading response header from upstream
503 复现
503,Service Unavailable,服务不可用;
如果你搜寻 503,大部分文章会通知你,这是服务器在保护或者过载,高并发下个别会呈现此状态值;
严格来说,除非是 DDoS 攻打之类间接导致服务器宕机了,否则高并发并不会间接触发 503,而是触发 502 才对;
参考下面的 502 复现场景,高并发最间接的影响是,没有足够的 PHP 过程来解决客户端申请,而个别 NGINX 承载的连接数是远远大于 PHP-fpm 的,所以问题大概率不是 NGINX 这里;
如果想复现 NGINX-503 谬误,能够通过设置 NGINX 的 连接数限度来复现;
具体路径是:设置 limit_conn
;
在 NGINX 配置文件中的 http 模块增加如下:limit_conn_zone $binary_remote_addr zone=per_ip:10m;
意思是:对用户 IP 进行并发计数,将计数内存区命名为 per_ip,设置计数内存区大小为 10MB;
之后在 http 模块下的 server 模块增加相似如下限度:
## 残缺配置 demo
http{
limit_conn_zone $binary_remote_addr zone=per_ip:10m;
server {
location /{
limit_conn per_ip 3; # 限度用户 ip 的并发连接数为 3
root……
index……
}
}
}
最初开启多线程,或者应用 ab 等压测工具,将并发数调到大于 3(因为下面的 demo 设置为最大连接数 3);
而后去拜访接口codetest.php
,即可复现 503 谬误。
因而,常见的 503 大多是 NGINX 开启了并发连接数限度导致,比方,你的接口被爬虫抓取;
如果是通过在 PHP 层通过 redis 限度拜访频次,则可抛出自定义的谬误,比方,401 等;
所以高并发呈现 503,并不是相对的,须要辩证的去对待,这里只是列举了一种可能。
504 复现
504,Gateway Timeout,网关超时。
它示意网关没有从上游及时获取响应数据。留神它和 502 在超时场景下的区别,502 是指上游 php-fpm 因为超过本身容许的执行工夫而不能失常生成响应数据,而 504 是指在 php-fpm 还未执行实现的某一时刻,因为超过了 nginx 本身的超时工夫,nginx 则认为上游 php-fpm 没有依照设置工夫返回响应数据就会返回 504,此时对于 php-fpm 而言还会继续执行上来,直到执行实现。
复现门路
代码:
`sleep(15);
echo ‘hello world’;`
php-fpm.conf
request_terminate_timeout=30
nginx
fastcgi_read_timeout 5;
codetest.php 脚本执行工夫须要 15s,小于 php-fpm 设置的一次申请的超时工夫 30s,所以 php 脚本可失常实现;
但 nginx 从 php-fpm 读取数据的超时工夫为 5s,所以在 5s 时,PHP 未执行实现,但 nginx 的超时等待时间到了,于是返回 504。
nginx 谬误日志
upstream timed out (110: Connection timed out) while reading response header from upstream
面试 Summary:
- 499 是因为超过客户端设置的申请超时工夫,客户端被动敞开连贯;
- 502 是因为 php-fpm 在本身的执行工夫要求内无奈按时实现,无奈返给 NGINX 失常的响应值;
- 504 是 php-fpm 在 NGINX 设置的超时工夫内无奈按时实现;
- 503 大多由 NGINX 开启了连接数限度后的高并发起因产生;
499,502,504,都是因超时而产生,区别在于,谁超了谁的时。
499 是超了客户端自身的连接时间;
502 是超了 php-fpm 的执行工夫;
504 是超了 NGINX 容许的最大读取工夫。