我在我的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命令文档：
时间复杂度：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
提前致谢。
答案 0 :(得分：5)
是否存在EC2 Micro实例的特征 对这些行动的表现产生不利影响。
Amazon EC2 Instance Type t1.micro有点独特，受定义严重限制，请参阅Micro Instances：
微实例（t1.micro）提供少量一致的CPU 资源，并允许您在短时间内增加CPU容量 额外的周期可用。 它们非常适合较低的 吞吐量应用程序和需要额外计算的网站 定期循环。 [强调我的]
后者原则上是正确的，但节流量令许多用户感到意外 - 虽然没有指定确切的算法，但文档解释并且特别是。很好地说明了一般策略和效果，一旦限制开始，实际上似乎产生约97％所谓的窃取时间，具体参见When the Instance Uses Its Allotted Resources部分：
我们希望您的应用程序只消耗一定量的CPU 一段时间内的资源。如果应用程序消耗超过 你的实例分配的CPU资源，我们暂时限制了 实例，因此它在低CPU级别运行。如果您的实例继续 要使用其所有分配的资源，其性能将降低。我们 将增加我们限制其CPU级别的时间，从而增加 允许实例再次爆发之前的时间。 [强调我的]
这显然使得任何表演测试的情绪确实如Didier Spezia rightly commented已经。请注意，虽然其他EC2实例类型也可能会显示窃取时间（这是虚拟化平台的一般工件，其中物理CPU可能由各种虚拟机共享），但相应的模式到目前为止更为规则因此，原则上可以进行性能测试，但以下约束条件通常适用：