redis - 在优化 redis 服务器的吞吐量后解释查询时间的峰值

Question

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

但还要注意查询时间是如何突然上升的(并且尖峰变得更高)!为什么会这样？

在我的代码中，我基本上用 setex 替换了 set 和 expire 对。我在凌晨 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 向您展示的内容，过期调用是快速调用并且正在降低平均值。您应该感兴趣的是总时间，即 每分钟通话次数*每次通话的平均时间，您肯定会从中受益。