4

我对部署在我的 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);

现在来自 Redislrange命令文档：

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

提前致谢。

4

1 回答 1

5

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

Amazon EC2 实例类型 t1.micro有些独特，并且根据定义受到严格限制，请参阅Micro Instances：

微型实例 (t1.micro) 提供少量一致的 CPU 资源，并允许您在有额外周期可用时在短时间内增加 CPU 容量。它们非常适合需要定期增加计算周期的低吞吐量应用程序和网站。[强调我的]

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

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

正如 Didier Spezia已经正确评论的那样，这显然会渲染任何性能测试的情绪。请注意，虽然其他 EC2 实例类型也可能表现出窃取时间（这是虚拟化平台的一般工件，其中物理 CPU 可能由各种虚拟机共享），但到目前为止，各自的模式更为规律，因此性能测试是原则上是可能的，但通常有以下限制：

  • 您至少需要在多个实例上运行测试，以解决由于相邻虚拟机上的随机 CPU 负载而导致的不同窃取时间量
  • 通常，您不应在与基准测试的虚拟机相同的虚拟机上运行基准测试应用程序，因为这显然会影响结果
于 2013-05-09T23:03:33.227 回答