AWS EC2 Micro Instance上的Redis性能

Question

I have made a funny observation on my Redis instance deployed on my AWS EC2 Micro instance ( Test environment)

I was measuring the execution times of various operations that have to hit Redis. To summarise, the execution times ( average) are shown below:

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)

Now what is worrying me are the first 2 operations ( the connection and the extraction of the top element in a list).

For the connection, the code is shown below:

 Jedis redis= new Jedis("localhost");

And for the extraction of the top element in the list:

 String currentDate = redis.lrange(holderDate,0,1).get(0);

Now from the Redis lrange Command documentation:

Time complexity: O(S+N) where S is the start offset and N is the number of elements in the specified range.

Now from my code S would be 0 and N would be 1.

My question then is: What is causing these execution times for these somewhat trivial operations.

Are there characteristics of the EC2 Micro instance that would adversely affect the performance of these operations.

Some key information on the Redis deployment:

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

Thanks in advance.

Answer 1

Are there characteristics of the EC2 Micro instance that would adversely affect the performance of these operations.

The Amazon EC2 Instance Type t1.micro is somewhat unique and heavily throttled by definition, see Micro Instances :

Micro instances (t1.micro) provide a small amount of consistent CPU resources and allow you to increase CPU capacity in short bursts when additional cycles are available. They are well suited for lower throughput applications and websites that require additional compute cycles periodically . [emphasis mine]

The latter is correct in principle, but the amount of throttling catches many users by surprise - while the exact algorithm isn't specified, the documentation explains and esp. illustrates the general strategy and effect pretty well, which in practice seems to yield around ~97% so called steal time once the throttling kicks in, see section When the Instance Uses Its Allotted Resources specifically:

We expect your application to consume only a certain amount of CPU resources in a period of time. If the application consumes more than your instance's allotted CPU resources, we temporarily limit the instance so it operates at a low CPU level. If your instance continues to use all of its allotted resources, its performance will degrade . We will increase the time we limit its CPU level, thus increasing the time before the instance is allowed to burst again. [emphasis mine]

This obviously renders any performance tests mood indeed, as Didier Spezia rightly commented already. Please note that while other EC2 instance types may also exhibit steal time (which is a general artifact of virtualization platforms, where physical CPUs might be shared by various virtual machines), the respective patterns are more regular by far in case, so performance tests are possible in principle, though the following constraints apply in general:

• you would need to run the tests on a number of instances at least to account for the varying amount of steal time due to random CPU loads on neighboring virtual machines
• you shouldn't run the benchmarking application on the same virtual machine as the benchmarked one in general, as this obviously impacts the result