共计 1824 个字符,预计需要花费 5 分钟才能阅读完成。
在 grafana 界面中发现不少 499 的状态码,在网上了解到出现 499 的原因大体都是说服务端处理时间过长,客户端主动关闭了连接。
既然原因可能是服务端处理时间太长了,看一下 upstream_response_time 时间可以了解到后端程序处理了多久。
先了解一下什么是 upstream_response_time 和 request_time 分别是什么:
- request_time:服务端从接受客户端请求的第一个字节到服务端应用程序处理完发送完响应数据的时间,包括请求数据时间、程序响应时间、输出响应时间
- upstream_response_time:指 nginx 向后端如 php,tomcat 等建立连接开始到到处理完数据关闭连接为止的时间
上面说过,原因可能是服务端处理时间太长了,那么应该 upstream_resopnse_time 和 request_time 时间很长才对。。看下图,打脸了,upstream_response_time 没有记录,request_time 也非常短,也就是说 nginx 根本没有将请求转发到 php 处理,而是直接返回了 499 状态码,所以没有 upstream_response_time,并且 request_time 时间很短,甚至为零。
这么说我这里出现 499 不是服务端处理时间太长了,而是另有他因。
看来百度是不行的,google 查找,原因可能是以下:
- 客户端请求速度过快,触发了 nginx 保护机制,直接返回 499 状态码
- 第二种情况就是客户端主动关闭了连接
- 证书错误
优化方法:
#size limits for 502 499
client_max_body_size 50m;
client_body_buffer_size 256k;
client_header_timeout 3m;
client_body_timeout 3m;
client_body_temp_path /dev/shm/client_body_temp;
send_timeout 3m;
proxy_ignore_client_abort on; # 告诉 nginx 不要主动关闭连接
proxy_connect_timeout 600;
proxy_read_timeout 600;
proxy_send_timeout 600;
proxy_buffer_size 32k;
proxy_buffers 4 64k;
proxy_busy_buffers_size 128k;
proxy_temp_file_write_size 512k;
CentOS 7.2 下编译安装 PHP7.0.10+MySQL5.7.14+Nginx1.10.1 http://www.linuxidc.com/Linux/2016-09/134804.htm
搭建基于 Linux6.3+Nginx1.2+PHP5+MySQL5.5 的 Web 服务器全过程 http://www.linuxidc.com/Linux/2013-09/89692.htm
CentOS 6.3 下 Nginx 性能调优 http://www.linuxidc.com/Linux/2013-09/89656.htm
CentOS 6.3 下配置 Nginx 加载 ngx_pagespeed 模块 http://www.linuxidc.com/Linux/2013-09/89657.htm
CentOS 6.4 安装配置 Nginx+Pcre+php-fpm http://www.linuxidc.com/Linux/2013-08/88984.htm
Nginx 安装配置使用详细笔记 http://www.linuxidc.com/Linux/2014-07/104499.htm
Nginx 日志过滤 使用 ngx_log_if 不记录特定日志 http://www.linuxidc.com/Linux/2014-07/104686.htm
Nginx 的 500,502,504 错误解决方法 http://www.linuxidc.com/Linux/2015-03/115507.htm
CentOS 7 编译安装 Nginx1.10.2 脚本启动失败解决思路 http://www.linuxidc.com/Linux/2017-01/139794.htm
Nginx 的详细介绍 :请点这里
Nginx 的下载地址 :请点这里
本文永久更新链接地址 :http://www.linuxidc.com/Linux/2017-01/140057.htm