Redis VS Memcached压力测试报告

一．测试背景与目标

了解Redis和memcached在高并发条件下的响应时间、吞吐量情况，以及对于服务器的压力情况（包括CPU、IO、网络）；考察目前的memcached存储timeline的方式的在高并发条件下的响应时间、吞吐量、负载情况，以及使用redis存储timeline的优势

二．测试环境

1.服务器

buzz090，刀片服务器

2.操作系统

CentOS release 5.5系统，内核版本：Linux version 2.6.18-194.el5

3.硬件

Intel(R) Xeon(R) CPU E5640 @ 2.67GHz 16CPU；48G内存；千兆网卡

4.软件：

uRedis版本：2.6.0-rc5（2.5.11），主要为了以后测试lua script功能，部署三个节点，每个节点开2G内存，共6G。开启AOF，策略every second；关闭RDB；开启lru，策略：allkeys-lru

uMemcached版本：1.4.5. 部署三个节点，每个节点开2G内存，共6G

5.客户端

buzz097，硬件环境、操作系统和buzz090一致。

客户端和服务器使用内网互联。

三．测试工具

1.Redis客户端

jedis，版本号2.1.0. 池设置使用默认，未调优。超时时间为5s

2.Memcached客户端

xmemcached，版本号1.3.5，使用一致性hash，使用BinaryCommandFactory，使用failure mode，不过未配置备机（-_-）.超时时间为5s

3.压力测试工具

海波写的压力测试框架（strike）

四．测试方法

1.测试方法

分别以100、200、500、1000个并发线程压力测试redis、memcached的方法，运行时间为20-60分钟不等，每轮压力测试取样3000次，压力测试中观察如下参数：

u单次操作的响应时间

u3000次操作的响应时间（吞吐量）

uCPU情况

u网络rx、tx

uIO

2.压力测试的方法

Redis：set、zadd、evalSha

Memcached：set、（gets、cas的操作组合）

3.一些说明

对于读操作做了少量测试，发现性能与set操作类似，就不做单独的测试报告了。读操作重要的一点是：在redis中，对于一个很大的sorted set，使用zrange时一定要指定范围，否则将得到大量的错误

五．测试用例：

1.Redis的set方法和memcached的set方法比较

u测试方法：使用java产生的伪随机数不断的对redis进行set操作，对memcached做set操作。

u测试结果：

Redis：

100个线程下，单次操作时间为0-1ms；运行3000次的时间为80-95ms，即吞吐量为32000-38000；CPU idle 96%；IO wr_sec/s为4000；网络rxKB/s：3000，txKb/s为1500-2000

200个线程下，单次操作时间0-1ms；运行3000次的时间为87-105ms，即吞吐量为28500-34500；CPU idle 96%；IO wr_sec/s为4000；网络rxKB/s：3000，txKb/s为1500-2000

500个线程下，单次操作时间0-1ms；运行3000次的时间为95-110ms，即吞吐量为27000-31500；CPU idle 96%；IO wr_sec/s为4000；网络rxKB/s：3000，txKb/s为1500-2000

1000个线程下，单次操作时间0-1ms；运行3000次的时间为97-120ms，即吞吐量为25000-30000；CPU idle 96%；IO wr_sec/s为4000；网络rxKB/s：3000，txKb/s为1500-2000

Memcached：

100、200、500个线程下，基本相差不大：单次操作时间；运行3000次的时间为65-85ms，即吞吐量为35000-46000；CPU idle 97%；IO wr_sec/s为260-350；网络rxKB/s：3000，txKb/s为3000

u小结

Memcached在小数据的写入方面性能要优于redis的，不仅吞吐量大，而且在服务器的负载、IO方面都有明显的优势。

Redis的关闭AOF后，性能大概上升了5%-10%，值得使用！

Redis在lru的时候感觉不到性能上的损耗

2.Redis的zadd方法和memcached的gets cas方法组合的比较：

u背景：目前微博的timeline使用memcached的gets cas组合的方式，实现乐观锁，保证timeline的一致性。

u测试方法：为redis构建37个sorted set，为memcached构建3700个key，并发的写入。其中redis使用zadd方法；memcached比较复杂，模拟当前微博系统中timeline的写入方式：从memcached中gets，将结果数组做二分查找，插入新的timeline，在java虚拟机中做数组的移动、cas回memcached中。

u测试结果

Redis：

100个线程下，单次操作时间为0-1ms；运行3000次的时间为80-95ms，即吞吐量为32000-38000；CPU idle 96%；IO wr_sec/s为5000；网络rxKB/s：5000，txKb/s为2500

200个线程下，单次操作时间0-1ms；运行3000次的时间为87-105ms，即吞吐量为28500-34500；CPU idle 96%；IO wr_sec/s为5000；网络rxKB/s：5000，txKb/s为2500

500个线程下，单次操作时间0-1ms；运行3000次的时间为95-110ms，即吞吐量为27000-31500；CPU idle 96%；IO wr_sec/s为5500；网络rxKB/s：5000-6000，txKb/s为2500

1000个线程下，单次操作时间0-1ms；运行3000次的时间为97-120ms，即吞吐量为25000-30000；CPU idle 96%；IO wr_sec/s为6000；网络rxKB/s：6000，txKb/s为2500

Memcached：

100个线程下：开始时单次写入时间以及3000次的写入时间均略优于redis，但是随着时间推移，一分钟后，3000次响应时间从80ms上升至250ms，五分钟后上升至400ms，十分钟后上升至600ms，二十分钟后接近800ms。单次响应时间也有类似的增长。

同时，网络rxKB/s：100000，txKb/s为100000

u小结

Redis的zadd方法在响应时间和吞吐量上与set方法基本无区别

当存储的数组很大时，memcached在网络性能、响应时间和吞吐量上均有较大程度的退步，而redis则无明显变化

对于timeline这样的数组的存储，redis更加适合！

3.Redis的zadd方法和Redis的lua script方法的比较

u背景：微博中的timeline分为两类：固定长度，长度无限增长。对应于redis，长度无限增长对应于zadd方法；

固定长度可以是用lua script脚本实现，具体的脚本为：

脚本中执行三次redis操作（zadd、zcard和zremrangebyrank），一次赋值、一次比较操作

Script在第一次时load到redis中，而后使用evalSha进行调用

u测试方法：分别构建37个sorted set，不断的用这两个方法、使用不同的线程数来压力测试

u测试结果：

Zadd（见上）

Lua script：

100个线程下：单次写入时间为2-5ms，3000次响应时间为105-115ms，即吞吐量为26000-28500；CPU idle 80%-90%；IO wr_sec/s为15000-22000；网络rxKB/s：5000-6000，txKb/s为2500

200个线程下：单次写入时间为7-9ms，3000次响应时间为112-120ms，即吞吐量为25000-27000；CPU idle 80%-90%；IO wr_sec/s为15000-22000；网络rxKB/s：5000-6000，txKb/s为2500

500个线程下：单次写入时间为12-21ms，3000次响应时间为125-135ms，即吞吐量为22000-24000；CPU idle 80%-90%；IO wr_sec/s为15000-22000；网络rxKB/s：5000-6000，txKb/s为2500

1000个线程下：单次写入时间为30-40ms，3000次响应时间为145-155ms，即吞吐量为19000-20500；CPU idle 80%-90%；IO wr_sec/s为15000-22000；网络rxKB/s：5000-6000，txKb/s为2500

如果每一次重新load script到服务器中，500个线程下：3000次响应时间为180-220ms，即吞吐量为13600-16600；CPU idle 80%-90%；IO wr_sec/s为15000-22000；网络rxKB/s：10000-12000，txKb/s为5000

u小结

以上lua脚本的性能大概是zadd的70%-80%，但是在可接受的范围内，在生产环境可以使用。负载大概是zadd的1.5-2倍，网络流量相差不大，IO是zadd的3倍（可能是开启了AOF，执行了三次操作？）

Lua一定要只load一次，然后循环使用，否则会有很大的性能缺失

Lua script所在的2.6.0-rc5版虽然不是stable版，官方网站也提到要在生产环境谨慎使用，但是测试下来没有发现bug

六．总结

1.Memcached在简单数据的写入上是有优势的，无论在响应时间、吞吐量、服务器的负载、IO、网络流量上都要优于redis

2.对于Timeline数组这样的数据，redis先天的类型丰富的优势可以极大的降低响应时间、提高吞吐量、提升服务器的性能指标。

3.Redis的zadd和set方法性能相差不大

4.Lua script可以实现在服务器端原子的执行多个操作的功能，性能大约是zadd的70-80%（和脚本的复杂程度有关），但是肯定比将脚本拆开单次的请求redis要好

5.AOF的开启会带来很小的性能损失，值得尝试

6.Redis在执行lru的时候，性能损失基本可以忽略