|
移动互联网场景中随着人机交互方式的改变，用户数据也发生了比较大的改变。从以1k以下的文本为主数据，变为1k~10k的音频占很大比例的数据。响应的后端服务的队列、存储、缓存也需要做一系列针对性调整。这里就简单记录一下maoyidao对Memcached的压测情况。 1. 压测工具：mcperfmcperf使用简单，输出报告清晰。最初是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 # git clone git://github.com/twitter/twemperf.git
# cd twemperf # autoreconf -fvi
我得到了一个错误，autoconf版本太低，需要升级。先看一下本机版本，然后下载安装2.65版本的autoconf。 # rpm -qf /usr/bin/autoconf
# wget http://ftp./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命令看一下版本号。 # CFLAGS="-ggdb3 -O0" ./configure --enable-debug
# 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
|
|
|
来自： WindySky > 《Memcached》
