移动互联网场景中随着人机交互方式的改变，用户数据也发生了比较大的改变。从以1k以下的文本为主数据，变为1k~10k的音频占很大比例的数据。响应的后端服务的队列、存储、缓存也需要做一系列针对性调整。这里就简单记录一下maoyidao对Memcached的压测情况。

1. 压测工具：mcperf

mcperf使用简单，输出报告清晰。最初是twitter为了证明其Twemcache在特定场景下（需要自动调节slab大小的场景下）比memcached强悍而开发的基准压测工具。比如在Random Eviciton vs Slab Automove（https://github.com/twitter/twemcache/wiki/Random-Eviciton-vs-Slab-Automove）一文中，就使用了mcperf作为基准压测工具。

1.1 安装

下载tar包，执行autoreconf

我得到了一个错误，autoconf版本太低，需要升级。先看一下本机版本，然后下载安装2.65版本的autoconf。

安装完毕，通过help命令看一下版本号。

1.2 压测命令

src/mcperf -s 172.16.138.88 -p 11211 --linger=0 --timeout=5 --conn-rate=1000 --call-rate=1000 --num-calls=10000 --num-conns=100 --sizes=u1024,10240

--num-conns=100是并发建立100个连接；--num-calls=10000是在一个连接上发1w个请求；--sizes是数据大小在1k和10k之间称正态分布；-conn-rate=1000是1秒钟建立1000个连接

2. 压测环境

2.1 启动Memcached

/usr/local/bin/memcached -d -m 1024 -p 11211 -u root

查看一下Memcached设置，主要关注：growth_factor、maxconns和evictions：

[maoyidao@yf03701 ~]$ printf "stats settings\r\n" | nc 172.16.138.123 11212

STAT maxbytes 0

STAT maxconns 4096

STAT tcpport 11212

STAT udpport 11211

STAT inter 172.16.138.123

STAT verbosity 0

STAT oldest 0

STAT evictions on

STAT domain_socket NULL

STAT umask 700

STAT growth_factor 1.25

STAT chunk_size 48

STAT num_threads 5

STAT stat_key_prefix :

STAT detail_enabled no

STAT reqs_per_event 20

STAT cas_enabled yes

STAT tcp_backlog 1024

STAT binding_protocol auto-negotiate

END

2.2 Memcached性能监控

下面介绍2个广泛使用的Memcached性能监控工具，在MC的实际使用中起到极大作用，每个使用MC的同学都应该熟练掌握。

2.2.1 memcached-tool

主要用于查看slab分配的情况，evction的情况。

https://github.com/memcached/memcached/blob/master/scripts/memcached-tool

[root@yf08801 maoyidao]# ./memcache-tool localhost:11211

  #  Item_Size  Max_age   Pages   Count   Full?  Evicted Evict_Time OOM

 19     5.5K      2080s      63   11587     yes     1791      710    0

 20     6.9K      2080s     234   34388     yes     5143      710    0

 21     8.7K      2080s     365   43057     yes     6600      710    0

 22    10.8K      2080s     365   34294     yes     5501      710    0

2.2.2 memcache-top

主要用于查看吞吐和hits情况。

http://code.google.com/p/memcache-top/

./memcache-top-v0.6 --instance 172.16.138.123,172.16.138.124 --port 11211

memcache-top v0.6       (default port: 11211, color: on, refresh: 3 seconds)

INSTANCE                USAGE   HIT %   CONN    TIME    EVICT/s READ/s  WRITE/s

172.16.138.123:11411    13.4%   96.1%   871     671.8ms 0.0     16.9K   39.4K

172.16.138.124:11411    13.3%   96.1%   865     660.6ms 0.0     20.8K   49.7K

AVERAGE:                13.4%   96.1%   868     666.2ms 0.0     18.9K   44.6K

TOTAL:          0.5GB/  4.0GB           1736    1.33s   0.0     37.8K   89.1K

3. 压测结果

3.1 总结

1，即使对于5k~10k大数据，mc的吞吐和延时表现也令人感到满意。

2，连接数需要控制，100个并发连接的延时是1000个并发连接的1%，吞吐也高了3倍。

3，大量的eviction对mc本身影响不大，但在这个场景显然需要预热。因为大数据会迅速占据所有slab空间，导致后面的小数据无内存可分，如下面的统计：

[root@yf08801 maoyidao]# ./memcache-tool localhost:11211

  #  Item_Size  Max_age   Pages   Count   Full?  Evicted Evict_Time OOM

 12     1.2K      3043s       1     885     yes     7837        5    0

 13     1.4K      3047s       1     708     yes    31336        1    0

 14     1.8K      3047s       1     564     yes    40180        1    0

 15     2.3K      3047s       1     451     yes    49471        1    0

 16     2.8K      3048s       1     361     yes    63140        0    0

 17     3.5K      3048s       1     288     yes    78878        0    0

 18     4.4K      3048s       1     230     yes    98750        0    0

 19     5.5K      3043s      63   11592     yes   117272        5    0

 20     6.9K      3037s     234   34398     yes   131097       11    0

 21     8.7K      3037s     365   43070     yes   163339       11    0

 22    10.8K      3037s     365   34310     yes   132305       11    0

3.2 原始数据摘要

数据大小：5k~10k，set 10w次；

1000个连接：3436.0 rsp/s;Response time [ms]: avg 178.0 min 0.0 max 2244.1 stddev 0.22

100个连接：9909.9 req/s；Response time [ms]: avg 0.6 min 0.1 max 2.4 stddev 0.00