背景
我们有一个公司级员工使用的系统,涉及的业务并发量不高,有几个管理员每个月都要去自定义上传和下载Excel数据,频度也不高,但是这个Excel数据需要经过非常多的验证和逻辑判定,由于是公司级内部员工使用的系统,硬件配置其实也不高。现象是最近管理员在上传和下载Excel数据的时候经常抛504异常。
所谓504异常,代表网关超时,是指服务器作为网关或代理,但是没有在规定超时时间内收到上游服务器收到的请求。
故障分析
首先,了解504异常的引发条件,总体上可以从Client和Server两个角度去看待504问题。
第一大类:从用户角度(Client),第一种情况:浏览器设置了代理服务,通过代理服务器访问网页,但是代理服务器不能再规定时间访问到服务。第二种情况:网络问题,就是你和服务器之间的网络连接出现了问题,比如你的电脑断网了。第三种情况:URL错误,比如输入一个错误的url。
第二大类:从网站管理员角度(Server),第一种情况:服务器负载过大,请求太多/慢请求太多,导致后面的来的请求没有在规定时间访问到服务。第二种情况:网关配置错误,业务你们公司在进行网络切割,导致网关(反向代理服务器、负载均衡器)配置错误,也可能导致504。第三种情况:服务器响应慢:服务器配置太低,性能太差。第四种情况:IIS/nginx/apache等服务被异常关闭了。第五种情况:数据库慢查询,数据库慢查询,导致查询超时了。第六种:程序逻辑问题,程序逻辑负载半天都在处理业务,紧到不返回内容,导致浏览器请求超时。
其次,分析本次异常最可能得问题,因为了解到最近并没有人去动网络配置也没有人去动服务器以及数据库,以及从请求日志看也没有请求爆炸的情况,并且用户也没有动浏览器,输入url也正确,所以Client可以排除,也可以排除服务器请求多,网关错误等,极有可能是系统经过日积月累的应用,数据增多了,用户下载的时候又要进行反复校验,也许也存在代码逻辑待优化,代码性能需提升的问题,但就集中在目前这个场景。
解决方案
我们需要快速让服务恢复正常,系统本来就没有几个人使用,我们不能一来就去纠结提升代码性能,排查Mysql慢查询可能得不偿失,我们最直接就是调整请求最大响应时间,把它加长了,可解决燃眉之急,让系统可用,第二阶段再去优化代码逻辑,解决数据库性能问题。明确了第一阶段目标接下来就简单多了
步骤一:梳理网络部署架构
不要一听架构就觉得特别复杂,毕竟这是一个简单的系统不存在多么复杂的网络架构,就是梳理请求流经的路径,比如:请求先经过了nginx代理、然后转到tomcat,再到具体应用进行执行,应用执行还要设计数据库的访问。
步骤二:调整这些步骤的请求等待时长
将这些服务的请求等待时长设置更大一点可解决80%的504问题,然后再去看服务是否正确了,大多数情况都能解决内部简单管理的504。
nginx超时时长,
-
keepalive_timeout
: 控制keep-alive连接的超时时间。 -
send_timeout
: 发送响应到客户端的超时时间。 -
client_body_timeout
: 客户端请求体读取超时时间。 -
client_header_timeout
: 客户端请求头读取超时时间。 -
fastcgi_read_timeout
: 用于FastCGI进程的读取响应超时。 -
proxy_read_timeout:代理超时等待时长
http {
...
server {
...
location / {
proxy_pass http://backend_server;
proxy_read_timeout 60s;
}
}
}
tomcat超时时长:
-
connectionTimeout
:在server.xml中的<Connector>
标签中设置,表示服务器等待连接建立的最长时间(以毫秒为单位)。 -
keepAliveTimeout
:在server.xml中的<Connector>
标签中设置,表示在Keep-Alive连接中等待下一个请求的最长时间(以毫秒为单位)。 -
connectionUploadTimeout
:在web.xml中设置,表示处理上传文件的最长时间(以毫秒为单位)。 -
asyncTimeout
:在web.xml中设置,表示异步处理请求的最长时间(以毫秒为单位)。 -
sessionTimeout
:在web.xml中设置,表示session失效的最长时间(以分钟为单位)。
<!-- server.xml中的Connector配置 -->
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
keepAliveTimeout="20000"
redirectPort="8443" />
步骤三:再去解决程序逻辑和慢SQL查询
排故心得
尽快让业务恢复使用,慢点就慢点,然后再去做一些更底层更深入的优化