测试环境准备
测试前需要先确认下自己的环境，避免测试环境本身成为性能瓶颈。
1 独占测试机器
包括跑JMeter的那些机器。
"top"或者"pidstat 1" 看一下，其他的应用都没用。如果是云主机，确保更多的占有宿主机的资源。
2 了解测试机器
必须完完全全的了解你的机器，才知道有没卡在某个瓶颈，或者与线上环境、其他测试结果的比较。
还是那句， 包括跑JMeter的那些机器。
2.1 CPU
"cat /proc/cpuinfo", 看最后一条就好，比如
processor : 23
model name : Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz
physical id : 1
cpu cores : 6
所有数字都从零开始，physical id:1即两颗cpu， cpu core: 6即6核，processor : 23即24个处理器。
2 CPU * 6 Core * 2HT(Intel超线程技术) = 24 Processor
不过也有很多同事喜欢说24核，也懒得纠正了。
2.2 内存
"free -g" 没什么好说的。
2.3 硬盘
- 查看大小、分区、文件系统类型： "df -hT"
- 硬盘是否SCSI：/dev/sdX就是scsi的，hdX就是普通的。
- 硬盘是否SSD : "cat /sys/block/sda/queue/rotational", 0是SSD，1是传统硬盘，但也不一定灵
普通硬盘的写速度大概100M/s，RAID级别的查看不方便，SSD的速度也不定，所以用dd测一下最靠谱:
dd if=/dev/zero of=dd.file bs=8k count=128k conv=fdatasync
dd if=/dev/zero of=./dd.file bs=1G count=1 conv=fdatasync
上面命令测试了分别以每次8k和1g的大小，写入1g文件的速度。
- if：输入文件名， /dev/zero 设备无穷尽地提供0
- of：输出文件名
- bs：块大小
- count：次数
- conv=fdatasync ：实际写盘，而不是写入Page Cache
硬盘读速度的测试同理，不过要先清理缓存，否则直接从Page Cache读了。
sh -c "sync && echo 3 > /proc/sys/vm/drop_caches”
dd if=./dd.file of=/dev/null bs=8k
dd命令多少会损伤磁盘，不适合经常用。
2.4 网卡
先用ifconfig看看有多少块网卡和bonding。bonding是个很棒的东西，可以把多块网卡绑起来，突破单块网卡的带宽限制。
然后检查每块网卡的速度，比如"ethtool eth0"。
再检查bonding，比如"cat /proc/net/bonding/bond0", 留意其Bonding Mode是负载均衡的，再留意其捆绑的网卡的速度。
查看网卡是否支持多队列，是否打开了多队列，最后确认每个队列是否绑定到不同的CPU。
最后检查测试客户机与服务机之间的带宽，先简单ping或traceroute 一下得到RTT时间，iperf之类的可稍后。
参考资料：Linux TCP队列相关参数的总结
2.5 操作系统
Linux的内核版本，是否64位： "uname -a"
Redhat/CentOS版本 : "cat /etc/redhat-release"
3. 布置机器状态采集工具
实时观察的，喜欢dstat，详见《从dstat理解Linux性能监控体系》比vmstat，iostat, sar们都好用，起码对得够齐，单位能自动转换。不过dstat需要安装(yum install dstat，或者去它的网站下载解压即用版)
- dstat -tamp：推荐，打印时间戳，比默认打印多一个memory信息，一个有否进程在block状态的信息
- dstat -tamN bond0,lo： 如果有bonding，dstat会把bond0和eth0 有时会算双份，还有lo的也算到总量里，所以先用-N指定网卡检查下。
参考资料：后台性能测试不可不知的二三事
nmon部署
java项目可以部署jmx的配置，使用jmc、jvisualvm这类工具进行监控。
参考资料：另一份Java应用调优指南之－工具篇
对应中间件需要监控的，也需要提前部署。
4. JMeter的调优顶一半的事
JMeter的版本越新越好。
4.1 JMeter的JVM参数
它默认连个垃圾收集算法都没有配，对延时要求高的，必须配上CMS或G1，内存也整大点降低GC的频率。其他的，给Server配的啥参数，给JMeter也来上一份。如果想动态改的，不写死在脚本里，可以配置环境变量$JVM_ARGS
4.2 测试计划的编写
什么if 语句，以及所有其实用动态语言来实现的都挺慢的。
xPath抽取结果集里的字段之类看着就慢的也别写了。
别加任何监听器和图形。
再配置输出日志的格式，能不要的列都别要了，最极端的其实就延时这列有用。
4.3 JMeter的运行
在Linux上用命令行跑，别偷懒用Window开着界面跑。
别开超过200条线程（虚拟机上更少）。
可以在不同机器上起多个JMeter，用集群汇总的模式。
4.4 结果的统计
初始连接，Server端热身，JVM编译热点方法等都需要时间，所以建议统计前删掉前面的一些日志。
要配置一下才能看到99.9%, 99.99% 分位数的延时，另外因为之前输出日志时省略了很多列，导入日志的时候配置也要如此。
但如果不能XWindows Forward，还要把日志下载回来再导入本地的JMeter，那还不如自己动动手，用sed, awk, sort配合一下自己写个分析延时的脚本直接在服务器上运行。
5. 其他被依赖的节点
比如所依赖的数据库够不够快，Restful API的模拟器够不够快，负载均衡器如HAProxy优化配置了没有。
浙公网安备 33010602011771号