这篇文章主要介绍“nginx读取超时问题案例分析”，在日常操作中，相信很多人在nginx读取超时问题案例分析问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”nginx读取超时问题案例分析”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
我们这个业务输出形式类似芝麻评分，部署架构是 接入层-》业务逻辑-》评分服务层。每个层对应一个物理进程。真正计算分数的就是评分服务层。我想按照这样的步骤依次查询问题：1 评分服务是否达到性能上线 2 是否业务逻辑层访问评分服务条件苛刻
我对评分服务的交易时间做了一个统计，样本量95w：
平均响耗时时间 301ms
标准查 238ms
最小耗时时间 6ms
前25%耗时时间 176ms
前75%耗时时间 372ms
前90%耗时时间 511ms
前99%耗时时间 993ms
最大耗时时间 15000ms
高于10秒的数量 26笔
没有处理失败的交易，但是有耗时比较长的交易，评分服务并没有达到上限。
为什么有的交易耗时超过10s？从业务的角度说，可能某个人的数据量大，计算占用io和cpu都比较大。
业务逻辑访问评分服务是通过nginx做反向代理的，最终请求是负载到多个服务器上。我们观察当时的nginx访问日志，发现有499的情况。
nginx引入的非标准的状态码，来表示当nginx正在处理请求时，客户端关闭了连接
我查询了业务逻辑层访问评分服务的时间：连接2秒，读取10秒。问题找到，当评分服务负载比较大时，处理某些请求的时间可能会超过10秒。因为业务逻辑层设置的读取超时时间10s，所以主动断开了连接。
方案1，修改业务逻辑层访问评分服务和接入层访问业务逻辑层的读取时间，大于评分服务正常处理请求的最大时间。缺点：这是治标不治本的方法，客户的体验比较差。
方案2，在评分服务层解决，找出消耗时间比较大的代码位置，考虑优化。缺点，周期比较长
方案3，横向拓展评分服务层。缺点，消耗机器资源（没那多的钱买机器）
我们统计了评分服务耗时时间相关指标，百分之99的交易均能在993ms，即1s内完成，真正耗时长的交易非常少，所以对整体的系统吞吐量基本构不成影响。
到此，关于“nginx读取超时问题案例分析”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注亿速云网站，小编会继续努力为大家带来更多实用的文章！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
