人工智能小冰开放AI设计平台

本地压测

我们分成两波同学，一波去准备本地压测，一波继续分析，经过本地压测，我们发现，本地环境，单机，1000个并发，妥妥的，毛问题都没有，平均响应基本维持在几百毫秒。

看来，确实跟服务本身没有问题。

代码走查

实在没有办法了，拿出代码，一群大老爷们一起看代码，研发同学给我们讲解业务逻辑，当然，他已经被各位大佬给骂死了，写的什么破代码，其实，在彤哥介入之前，他们已经改过一波代码了，有个地方把redis命令scan改成了keys *，这里埋了个坑，但是，现在不是主要问题，后面我们会说。

代码一路走读下来，发现有很多的redis操作，还有个for循环里面在调redis的get命令，其它的都是常规的数据库操作，而且都加了索引的，所以，初步排查，数据库这里应该是没有什么问题，主要问题可能还是集中在redis这块，调用太频繁了。

加日志

代码走查下来，除了那个scan改成了keys *(这个我还不知道)，基本上没有什么问题，加日志吧， 一小段一小段的加上日志，OK，重启服务，压测来一波。

当然了，结果没有什么变化，分析日志。

通过日志，我们发现，调用redis的时候时而很快，时而很慢，看起来像是连接池不够的样子，也就是一批请求先行，一批请求在等待空闲的redis连接。

修改redis连接数

查看redis配置，用的是单机模式，1G内存， 连接数默认的8，客户端还是比较老的jedis，果断改成springboot默认的lettuce，连接数先调整为50，重启服务，压一波。

平均响应时间从3~4秒降到了2~3秒，并不明显，继续加大连接数，因为我们是1000个并发，每个请求都有很多次redis操作，所以，肯定会有等待，这次我们把连接数直接干到了1000，重启服务，压一波。

事实证明，并没有明显地提升。

再次查看日志

此时，已经没有什么好的解决办法了，我们再次回到日志中，查看redis相关操作的时间，发现99%的get操作都是很快返回的，基本上是在0~5毫秒之间，但是，总有那么几个达到了800~900毫秒才返回。

我们以为redis这块没什么问题了。

但是，压测了好几次，时间一直提不上去。

很无奈了，此时，已经半夜3点多了，领导发话，把华为云的人喊起来。

华为云排查

最后，我们把华为云相关的人员喊起来一起排查问题，当然，他们是不情愿的，但是，谁让我们给钱了呢^^

华为云的负责人，把redis的专家搞起来，帮我们看了下redis的指标，最后，发现是redis的带宽满了，然后触发了限流机制。

他们临时把redis的带宽增大三倍，让我们再压测一波。

握了颗草，平均响应时间一下子降到了200~300毫秒!!!!

真的是握了颗草了，这就有点坑了，你限流就算了，带宽满了也不报警一下的么。。

这真是个蛋疼的问题。

到这里，我们以为问题就这样解决了，领导们也去睡觉了~~

上生产

既然问题原因找到了，那就上生产压一波吧~

我们让华为云的专家把生产的带宽也增大了三倍大小。

从生产提交拉一个hotfix分支，关闭签名，重启服务，压测走一波。

完蛋，生产环境更差，平均响应时间在5~6秒。

测试环境我们是改了连接池配置的，生产环境还是jedis，改之，走一波。

并没有什么实际作用，还是5~6秒。

真是个蛋疼的问题。

查看监控

查看华为云中redis的监控，这次带宽、流控都是正常的。

这次不正常的变成了CPU，redis的CPU压测的时候直接飙到了100%，导到应用响应缓慢。

再次唤醒华为云redis专家

已经凌晨四点多了，大家已经没什么思路了，华为云的redis专家，你给我再起来!

再次唤醒华为云的redis专家，帮我们分析了下后台，发现10分钟内进行了14万次scan~~

（编辑：新余站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!