http://blog.chinaunix.net/uid-8625039-id-4749801.html
redis 集群性能测试以及与单机性能对比(1)中针对于相同硬件，不同网络环境，不同并发数以及数据大小进行了测试，虽只是针对于set进行测试，但也能大体反映出不同条件下对性能的影响。接下来的测试主要针对于某个特定条件下，分析导致测试结果上限的瓶颈在哪。
同样还是使用linux系统性能分析工具nmon,具体使用参考
linux下使用性能分析工具nmon，本次测试采用一个比较通用的数据：redis-benchmark -h 192.168.1.73 -p 25040 -t SET -n 10000000 -c 1000 -d 1024 -q，1000个并发，每次写入1kbytes数据，持续执行100000000次
，持续监测10分钟。
执行结果:
[
lee@
localhost press_test_for_rival_pvp]$ redis-benchmark -h 192.168.1.73 -p 25040 -t SET -n 100000000 -c 1000 -d 1024 -q
SET: 51785.11 requests per second
同时监控三台机器，71,73,74，分别为redis-beanchmark,twemproxy,redis所在部署的机器；以下图表为nmon生成图表，若不做特殊说明，同一监控指标的顺序为71,73,74。
SYS_SUMM
从上表可以看出，CPU的平均使用率约为10%左右，比较空闲；73的TPS值比较高，不过目前还不太明白这个有什么影响。按定义来说的话，TPS为每秒处理的请求数，71为测试机，TPS的平均值仅仅为8，也就是说每秒处理8个请求，实际应该是50000+，完整的参数名为Avg tps during an interval，不知道这个interval具体是多少，暂时忽略吧！
DISK_SUMM
总体disk读、写以及I/O操作。71磁盘写值最高，峰值在1400kbytes；磁盘I/O次数74值最高，峰值4500左右，并且看分布，应该是一分钟左右写一次磁盘；
DISKBUSY
diskbusy为每个disk设备的平均占有情况，
73的最大值已经达到100%了，但只是短暂的，并不持续的，此处可能是不是瓶颈。
MEM
主图上显示空闲实存的数量。由上看出内存使用平稳，没什么问题！
上图t显示系统中每个网络适配器的数据传输速率（千字节/秒）。网络流量基本达到50~60M，内网为千M网卡，也没有达到上限.
NETPACKET
上图统计每个适配器网络读写包的数量；这个类似于netpmon –O dd 命令
遗憾的是，穷举了这么多的图表，却找不到系统的瓶颈在哪，能力有限。如果大伙能从图中看出来，也麻烦指出，三克油！
参考：