在优化redis-server的吞吐量后，解释查询时间的峰值

Question

我优化了我对应用程序的redis-server进行的一些调用，大大减少了expire次调用的次数。了解吞吐量如何下降：

但是还要注意查询时间是如何突然上升的（并且峰值变得更高）！为什么会发生这种情况？

我在代码中基本上用set替换了expire和setex对。我在凌晨2:15左右进行了一次优化，然后在凌晨2:45左右进行了另一次优化。请注意查询时间如何仅在后一种情况下跳跃。

这只是New Relic的一个怪癖，还是有一个以Redis为中心的解释？我的总体目标是尽可能保持整个过程和查询时间。如果您需要更多信息，请与我们联系。

Answer 1

假设您每分钟有500个电话，400个快速和100个慢速类型。快速的需要100ms，慢速的需要500ms。 所以newrelics会将平均时间显示为：

(400*100 + 100*500)/(400+100) = 180ms.

现在你结合了一些电话，而且大多数便宜的电话从之前的设置中被淘汰，新发行版就是0快速通话和100个慢速通话。

(0*100 + 100*500)/(0+100)  = 500ms.

这正是NewRelic向您展示的内容，过期呼叫是快速呼叫并且正在降低平均值。 你应该感兴趣的是整个时间，即calls per minute*average time per call，你肯定会受益。