Kri*_*rri 4 java amazon-ec2 redis jedis
我在部署在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)
Run Code Online (Sandbox Code Playgroud)
现在令我担心的是前两个操作(连接和列表中顶部元素的提取).
对于连接,代码如下所示:
Jedis redis= new Jedis("localhost");
Run Code Online (Sandbox Code Playgroud)
并且为了提取列表中的顶部元素:
String currentDate = redis.lrange(holderDate,0,1).get(0);
Run Code Online (Sandbox Code Playgroud)
现在来自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
Run Code Online (Sandbox Code Playgroud)
提前致谢.
是否存在EC2 Micro实例的特性会对这些操作的性能产生负面影响.
在Amazon EC2实例类型 t1.micro是很独特和定义重节流,见微实例:
微实例(t1.micro)提供少量一致的CPU资源,并允许您在有额外周期时以短突发方式增加CPU容量.它们非常适用于需要额外计算周期的低吞吐量应用程序和网站.[强调我的]
后者原则上是正确的,但节流量令许多用户感到意外 - 虽然没有指定确切的算法,但文档解释并且特别是.很好地说明了一般的策略和效果,实际上,一旦限制开始,实际上似乎产生大约97%的所谓的窃取时间,请参阅实例使用其分配的资源时的具体部分:
我们希望您的应用程序在一段时间内仅消耗一定量的CPU资源.如果应用程序消耗的内存超过实例分配的CPU资源,我们会暂时限制实例,使其在低CPU级别运行.如果您的实例继续使用其所有分配的资源,其性能将下降.我们将增加限制其CPU级别的时间,从而增加允许实例再次爆发之前的时间.[强调我的]
这显然使得任何表演测试的情绪确实如同Didier Spezia 已正确评论.请注意,虽然其他EC2实例类型也可能显示窃取时间(这是虚拟化平台的一般工件,其中物理CPU可能由各种虚拟机共享),但相应的模式在更多情况下更加规则,因此性能测试是原则上可能,但以下限制一般适用: