在AWS EC2微实例上的Redis性能

4

我在我的部署在AWS EC2微实例(测试环境)上的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

感谢您的提前帮助。

2
EC2微实例被严重限制。在我看来,试图在它们上运行基准测试(甚至解释性能测量)是浪费时间。 - Didier Spezia
@DidierSpezia:这是可以理解的,但是为了使应用程序表现出这种性能统计数据,需要限制哪些机器特性?请注意,Redis实例部署在与对其进行基准测试的应用程序相同的节点上。谢谢。 - Kris Ogirri
1个回答

5

EC2微实例是否有特征会对这些操作的性能产生负面影响?

Amazon EC2实例类型 t1.micro 是独特的并且被定义为强制限制,详见Micro Instances:

微实例(t1.micro)提供一小部分持续的CPU资源,并允许您在额外的计算周期可用时短暂地增加CPU容量。 它们非常适合低吞吐量的应用程序和需要周期性增加计算周期的网站[我强调的]

后者在原则上是正确的,但许多用户会被限制的数量所吓到 - 虽然没有指定确切的算法,但文档很好地解释了特定策略和效果,尤其是通过插图来说明,在实践中似乎会产生约 ~97% 的所谓 “steal time” ,一旦限制开始,可以参见当实例使用其分配的资源部分:

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

正如Didier Spezia 正确地评论的那样,这显然确实会使任何性能测试的心情受到影响。请注意,虽然其他EC2实例类型也可能表现出偷取时间(这是虚拟化平台的一般特征,物理CPU可能由各种虚拟机共享),但相应的模式在情况下要规则得多,因此原则上可以进行性能测试,但通常存在以下限制:

  • 您至少需要在多个实例上运行测试,以考虑由于相邻虚拟机上的随机CPU负载而导致的不同偷取时间量
  • 通常不应该在被基准测试的虚拟机上运行基准测试应用程序,因为这显然会影响结果

我理解你的观点,但我仍然在思考AWS EC2限流如何影响每次执行同一代码的简单200ms应用程序。这对我来说听起来很奇怪。如果代码在服务器内运行,我可以理解,但这是按需运行的。不过,“Steal Time”还是值得一提的 :) - Kris Ogirri

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接