AWS EC2 微实例上的 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 命令文档：

时间复杂度：O(S+N)，其中 S 是起始偏移量，N 是指定范围内的元素个数。

现在从我的代码中，S 为 0，N 为 1。

然后我的问题是：是什么导致了这些有些琐碎的操作的执行时间。

EC2 微型实例的特性是否会对这些操作的性能产生不利影响。

关于 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 微型实例的特性是否会 对这些操作的性能产生不利影响。

Amazon EC2 Instance Typet1.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 可能由各种虚拟机共享），但到目前为止，各自的模式更为规律以防万一，因此原则上可以进行性能测试，但通常存在以下限制：

• 您至少需要在多个实例上运行测试，以解决由于相邻虚拟机上的随机 CPU 负载导致的不同窃取时间量
• 一般而言，您不应在与基准测试的虚拟机相同的虚拟机上运行基准测试应用程序，因为这显然会影响结果