移动互联网场景中随着人机交互方式的改变，用户数据也发生了比较大的改变。从以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
# cd twemperf
# autoreconf -fvi
我得到了一个错误，autoconf版本太低，需要升级。先看一下本机版本，然后下载安装2.65版本的autoconf。
# wget http://ftp.gnu.org/gnu/autoconf/autoconf-2.65.tar.gz
# tar -xzvf autoconf-2.65.tar.gz
# cd autoconf-2.65
# ./configure --prefix=/usr
# make
# make install
# /usr/bin/autoconf -V
安装完毕，通过help命令看一下版本号。
# make
# src/mcperf -h
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