我们已经开始在应用程序中使用redis来持久化api响应。我选择使用stackexchange.redis来处理它,在实现了保存响应的整个逻辑之后,压力测试的结果变得非常令人失望。应用程序的总吞吐量降低了3-4倍!它大约是550-600转/秒,现在大约是180转/秒(甚至更慢)。
在压力测试过程中,有时根本没有异常,但有时会发生超时异常,如下所示:
Timeout awaiting response (5094ms elapsed, timeout is 5000ms), inst: 0, qs: 10, in: 65536, mgr: 10 of 10 available, IOCP: (Busy=26,Free=974,Min=8,Max=1000), WORKER: (Busy=3,Free=32764,Min=8,Max=32767), v: 2.0.513.63329
Timeout awaiting response (5063ms elapsed, timeout is 5000ms), inst: 0, qs: 4, in: 47355, mgr: 10 of 10 available, IOCP: (Busy=40,Free=960,Min=8,Max=1000), WORKER: (Busy=34,Free=32733,Min=8,Max=32767), v: 2.0.513.63329
The timeout was reached before the message could be written to the output buffer, and it was not sent (5000ms, inst=3, qs=3, in=10, active=HMSET), inst: 3, qs: 3, in: 10, mgr: 10 of 10 available, IOCP: (Busy=36,Free=964,Min=8,Max=1000), WORKER: (Busy=34,Free=32733,Min=8,Max=32767), v: 2.0.513.63329
下面是上一次压力测试期间发生的所有超时异常的总体概览:
我曾尝试实现连接池(基于totaloutstanding属性),尝试减少对redis的请求数量,等等,但都没有帮助。
我执行了show log和latency doctor命令,但似乎我们的redis实例没有问题(尽管我们已经按照医生的建议禁用了thp)。
我的假设是,一些非常大的api响应会阻止其他请求完成。我认为是因为高的入站流量值。对吗?怎么办?我需要以某种方式分离请求吗?
