AWS EC2 Micro Instance上的Redis性能

我在部署在AWS EC2 Micro实例上的Redis实例上做了一个有趣的观察(测试环境)

我正在测量必须击中Redis的各种操作的执行时间.总而言之,执行时间(平均值)如下所示:

Jedis -> Redis Connection is 63 milliseconds
Read of top Element in a list using lrange(,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 lrangeCommand文档:

时间复杂度: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

提前致谢.

是否存在EC2 Micro实例的特性会对这些操作的性能产生负面影响.

在Amazon EC2实例类型 t1.micro是很独特和定义重节流,见微实例:

微实例(t1.micro)提供少量一致的CPU资源,并允许您在有额外周期时以短突发方式增加CPU容量.它们非常适用于需要额外计算周期的低吞吐量应用程序和网站.[强调我的]

后者原则上是正确的,但节流量令许多用户感到意外 - 虽然没有指定确切的算法,但文档解释并且特别是.很好地说明了一般的策略和效果,实际上,一旦限制开始,实际上似乎产生大约97%的所谓的窃取时间,请参阅实例使用其分配的资源时的具体部分:

我们希望您的应用程序在一段时间内仅消耗一定量的CPU资源.如果应用程序消耗的内存超过实例分配的CPU资源,我们会暂时限制实例,使其在低CPU级别运行.如果您的实例继续使用其所有分配的资源,其性能将下降.我们将增加限制其CPU级别的时间,从而增加允许实例再次爆发之前的时间.[强调我的]

这显然使得任何表演测试的情绪确实如同Didier Spezia 已正确评论.请注意,虽然其他EC2实例类型也可能显示窃取时间(这是虚拟化平台的一般工件,其中物理CPU可能由各种虚拟机共享),但相应的模式在更多情况下更加规则,因此性能测试是原则上可能,但以下限制一般适用:

您需要在多个实例上运行测试,至少要考虑由于相邻虚拟机上的随机CPU负载导致的不同的窃取时间

您不应该在与基准测试的虚拟机相同的虚拟机上运行基准测试应用程序,因为这显然会影响结果