读取超时问题记录

前言

之前我们有一个业务在负载大的情况下超时多，领导下令消灭超时交易。义不容辞干吧。

问题描述

我们这个业务输出形式类似芝麻评分，部署架构是 接入层-》业务逻辑-》评分服务层。每个层对应一个物理进程。真正计算分数的就是评分服务层。我想按照这样的步骤依次查询问题：1 评分服务是否达到性能上线 2 是否业务逻辑层访问评分服务条件苛刻

1 评分服务是否达到性能上线

我对评分服务的交易时间做了一个统计，样本量95w：

• 平均响耗时时间 301ms
• 标准查 238ms
• 最小耗时时间 6ms
• 前25%耗时时间 176ms
• 前75%耗时时间 372ms
• 前90%耗时时间 511ms
• 前99%耗时时间 993ms
• 最大耗时时间 15000ms
• 高于10秒的数量 26笔

没有处理失败的交易，但是有耗时比较长的交易，评分服务并没有达到上限。

为什么有的交易耗时超过10s？从业务的角度说，可能某个人的数据量大，计算占用io和cpu都比较大。

2 是否业务逻辑层访问评分服务条件苛刻

业务逻辑访问评分服务是通过nginx做反向代理的，最终请求是负载到多个服务器上。我们观察当时的nginx访问日志，发现有499的情况。

nginx 499 CLIENT CLOSED REQUEST

nginx引入的非标准的状态码，来表示当nginx正在处理请求时，客户端关闭了连接

我查询了业务逻辑层访问评分服务的时间：连接2秒，读取10秒。问题找到，当评分服务负载比较大时，处理某些请求的时间可能会超过10秒。因为业务逻辑层设置的读取超时时间10s，所以主动断开了连接。

方案

方案1，修改业务逻辑层访问评分服务和接入层访问业务逻辑层的读取时间，大于评分服务正常处理请求的最大时间。缺点：这是治标不治本的方法，客户的体验比较差。

方案2，在评分服务层解决，找出消耗时间比较大的代码位置，考虑优化。缺点，周期比较长

方案3，横向拓展评分服务层。缺点，消耗机器资源（没那多的钱买机器）

潜在的问题

增大客户端的读取时间，是否会影响整体系统的吞吐量

我们统计了评分服务耗时时间相关指标，百分之99的交易均能在993ms，即1s内完成，真正耗时长的交易非常少，所以对整体的系统吞吐量基本构不成影响。

后记

遇到问题，分析问题，以事实说话。

stay hungry, stay foolish

转载于:https://my.oschina.net/huaxiaoqiang/blog/3078553