Cloud Redis延遲原因（與Macbook Pro上的本地Redis）

Question

Redis可以給出不到毫秒的響應時間。 這是一個很大的希望。 我正在測試heroku redis，對於zincrby ，我得到1ms到大約8ms的zincrby 。 我在php中使用microtime()來包裝調用。 這個heroku redis（我正在使用免費計划）是一個共享實例，並且存在資源爭用，因此我希望相同查詢的響應時間會有所不同，而且肯定會。

我很好奇通過自制軟件在Macbook Pro上安裝的性能與Redis的性能差異的原因。 那里顯然沒有網絡延遲。 我很好奇的是，這是否意味着與我擁有一台雲服務器並在內部運行redis相比，任何雲redis（即通過網絡連接，例如在AWS中）總是會慢很多。同一台物理計算機，從而消除了網絡延遲？

這些雲產品中也存在資源爭用，除非選擇了價格昂貴的私有服務器。

一些數字：我的本地macbook pro始終為相同的zincrby提供0.2ms的時間，在heroku redis上花費1ms至8ms時間。

網絡延遲是造成這種情況的原因嗎？

Answer 1

不，可能不會。

1 Gbit / s網絡的典型延遲約為200us 。 那是0.2ms 。

而且，在aws中，您的速度可能至少為10gbps。

正如redis手冊中的該頁面所解釋的那樣，這兩種環境之間的延遲變化的主要原因幾乎肯定是intrinsic latency較高的結果（有redis命令可以在任何特定系統上對此進行測試： redis-cli --intrinsic-latency 100 ，請參見上面的手冊頁）是由於在linux容器中運行而引起的 。

也就是說，網絡延遲不是此處變化的主要原因。

這是一個清單（來自上面鏈接的redis手冊頁）。

• 如果負擔得起，則最好使用物理機而不是VM來承載服務器。
• 不要系統地連接/斷開與服務器的連接（對於基於Web的應用程序尤其如此）。 保持連接盡可能長久。
• 如果客戶端與服務器位於同一主機上，請使用Unix域套接字。
• 最好在管道上使用聚合命令（MSET / MGET）或帶有可變參數的命令（如果可能）。
• 優先在往返序列上使用流水線（如果可能）。
• Redis支持Lua服務器端腳本來覆蓋不適合原始流水線的情況（例如，當命令的結果是以下命令的輸入時）。