AWS EC2 Micro Instance上的Redis性能

Question

我在部署在AWS EC2 Micro實例上的Redis實例上做了一個有趣的觀察（測試環境）

我正在測量必須擊中Redis的各種操作的執行時間。 總而言之，執行時間（平均值）如下所示：

Jedis -> Redis Connection is 63 milliseconds
Read of top Element in a list using lrange(<listname>,0,1) is 44 milliseconds
Read of entire Elements of set is 5ms
Iteration over entire Set space is 60ms( Set space  approx 130 elements)
Iteration over subset of elements of set is 5ms ( Subset element size is 5)

現在令我擔心的是前兩個操作（連接和列表中頂部元素的提取）。

對於連接，代碼如下所示：

 Jedis redis= new Jedis("localhost");

並且為了提取列表中的頂部元素：

 String currentDate = redis.lrange(holderDate,0,1).get(0);

現在來自Redis lrange Command文檔：

時間復雜度：O（S + N）其中S是起始偏移量，N是指定范圍內的元素數量。

現在從我的代碼S將是0和N將是1。

我的問題是：這些有些微不足道的操作導致這些執行時間的原因。

是否存在EC2 Micro實例的特性會對這些操作的性能產生負面影響。

關於Redis部署的一些關鍵信息：

redis_version:2.4.10
used_memory:2869280
used_memory_human:2.74M
used_memory_rss:4231168
used_memory_peak:2869480
used_memory_peak_human:2.74M
mem_fragmentation_ratio:1.47

提前致謝。

Answer 1

是否存在EC2 Micro實例的特性會對這些操作的性能產生負面影響。

Amazon EC2實例類型 t1.micro有些獨特且受定義嚴重限制，請參閱Micro Instances ：

微實例（t1.micro）提供少量一致的CPU資源，並允許您在有額外周期時以短突發方式增加CPU容量。 它們非常適用於需要額外計算周期的低吞吐量應用程序和網站 。 [強調我的]

后者原則上是正確的，但節流量令許多用戶感到意外 - 雖然沒有指定確切的算法，但文檔解釋並且特別是。 很好地說明了一般的策略和效果，實際上，一旦限制開始，實際上似乎產生大約97％的所謂的竊取時間 ，請參閱實例使用其分配的資源時的具體部分：

我們希望您的應用程序在一段時間內僅消耗一定量的CPU資源。 如果應用程序消耗的內存超過實例分配的CPU資源， 我們會暫時限制實例，使其在低CPU級別運行。 如果您的實例繼續使用其所有分配的資源，其性能將下降 。 我們將增加限制其CPU級別的時間，從而增加允許實例再次爆發之前的時間。 [強調我的]

這顯然使得任何表演測試的情緒確實如同Didier Spezia已正確評論 。 請注意，雖然其他EC2實例類型也可能顯示竊取時間 （這是虛擬化平台的一般工件，其中物理CPU可能由各種虛擬機共享），但相應的模式在更多情況下更加規則，因此性能測試是原則上可能，但以下限制一般適用：

• 您需要在多個實例上運行測試，至少要考慮由於相鄰虛擬機上的隨機CPU負載導致的不同的竊取時間
• 您不應該在與基准測試的虛擬機相同的虛擬機上運行基准測試應用程序，因為這顯然會影響結果