在优化redis服务器的吞吐量之后解释查询时间中的秒杀

Question

我优化了我对应用程序的redis服务器进行的一些调用，显着减少了expire调用的次数。查看吞吐量下降：

但也注意到查询的时候怎么突然上升（和尖峰成为高）！为什么会发生？

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

难道这只是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，你一定会从中受益。