缘由：前段时间只是看了小强的视频，跟着视频做一些实验，这种学习方式总会给人一种 ‘我学的是假Jmeter’ 的错觉，这周有个项目需要做压力测试，我便做个全程记录，以后自己用到也回来看看，毕竟很长时间不做就忘记了。
业务场景：可知某系统A目前是2台机器承受10Ｗ用户，以后用户会扩展到200Ｗ，问：大概需要多少台机器？
测试思路：在window本机上创建测试计划形成 .jmx。然后拿到linxu系统去跑测试计划进行打压
1.jmeter安装
1）window系统，下载.zip包解压，添加环境变量，就ok . windows系统安装jmeter
2)linux安装，下载tar.gz包解压，添加环境变量，linux系统安装jmeter
cat /etc/profile
#JDK配置
export JAVA_HOME=/opt/product/test/tools/jdk1.8.0_111
export PATH=$JAVA_HOME/bin:$PATH
export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar
#Jmeter配置
export JMETER=/opt/apache-jmeter-3.0
export CLASSPATH=${JMETER}/lib/ext/ApacheJMeter_core.jar:${JMETER}/lib/jorphan.jar:$JMETER/lib/logkit-2.0.jar:${CLASSPATH}
export PATH=${JMETER}/bin/:${PATH}
验证是否安装好,返回如下的信息就代表安装好了
[root@localhost bin]# java -version
java version "1.8.0_111"
Java(TM) SE Runtime Environment (build 1.8.0_111-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.111-b14, mixed mode)
[root@localhost bin]#
[root@localhost bin]# jmeter -v
Writing log file to: /opt/apache-jmeter-3.0/bin/jmeter.log
_ ____ _ ____ _ _ _____ _ __ __ _____ _____ _____ ____
/ \ | _ \ / \ / ___| | | | ____| | | \/ | ____|_ _| ____| _ \
/ _ \ | |_) / _ \| | | |_| | _| _ | | |\/| | _| | | | _| | |_) |
/ ___ \| __/ ___ \ |___| _ | |___ | |_| | | | | |___ | | | |___| _ <
/_/ \_\_| /_/ \_\____|_| |_|_____| \___/|_| |_|_____| |_| |_____|_| \_\ 3.0 r1743807
Copyright (c) 1999-2016 The Apache Software Foundation
[root@localhost bin]#
1.在windows环境录制测试计划
1）打开jmeter,创建测试计划（线程组-sampler(HTTP请求-监听器（查看结果树、聚合报告）)）
HTTP请求，填写IP，端口，请求方法，路径，参数名称和值
以上截图中的参数名称是接口文档里面定义的，值是我们设定的。设定参数值的方法很多，第一个方法 是在文件中取值，比如第一个参数 UserID 是在一个文件中去的，如果在文件中取值需要添加 配置元件(CSV Date Set Config)进行参数化，如下图：
取参数也可以通过函数 动态生成数据，如 ${__RandomString(8,324YFHDDN0098432U2J32EWWDDYEHD,)}指在后面的字符中随机取8个数字。
查看结果树和聚合报告是用来查看执行计划是否成功以及各项指标的。
最后把跑通的脚本保存为 .jmx文件。
2.在linux环境执行测试计划（打压）
把脚本上传到 linxu环境，可以在脚本里面直接修改参数（并发数、运行时间、参数文件的位置）
在 jmeter 的bin目录下执行测试计划，执行命令如下;
jmeter -n -t ncindex-collect.jmx -l result.jtl -e -o ResultReport
#ncindex-collect.jmx是脚本名字，result.jtl 是生成的日志文件，ResultReport是生成的报告目录
· -h 帮助 -> 打印出有用的信息并退出
· -n 非 GUI 模式 -> 在非 GUI 模式下运行 JMeter
· -t 测试文件 -> 要运行的 JMeter 测试脚本文件
· -l 日志文件 -> 记录结果的文件
· -r 远程执行 -> 启动远程服务
· -H 代理主机 -> 设置 JMeter 使用的代理主机
· -P 代理端口 -> 设置 JMeter 使用的代理主机的端口号
执行命令后还需要观察打压过程是否有报错，监控linux服务器的cpu 、内存、负载等。
如果脚本过程有报错，还要去监控应用的日志，我在打压的时候应用日志就报了内存泄露;
这时候需要分析内存泄露在什么地方，什么地方占用内存，执行命令：
jmap -dump:format=b,file=mem.dat PID
dump下来的文件需要用工具分析，具体使用工具 Memory Analyzer,是一个eclipse插件 ，也可以单独使用，安装以及使用方法见 ：
内存分析工具MAT(Memory Analyzer Tool)从安装到使用
性能分析工具之-- Eclipse Memory Analyzer tool(MAT)（二）
使用 Eclipse Memory Analyzer 进行堆转储文件分析
分析后会生成的报告见：
大体意思就是 大部分的内存泄露是因为 "java.util.concurrent.ConcurrentHashMap$Node[]" 还可以看具体报告的细节，虽然看不大懂，但是知道肯定是代码引起的。打压过程还有个很奇怪的现象就是打压完成后 内存和cpu好久都下不来，这明显是不正常的。对比图如下：
后来就把报告发给研发分析，也发给我们经理看了下，最终他们给出的结果是 被压的页面没有关闭session，如下修改：
<%@ page session="false" contentType="text/html;charset=UTF-8" language="java"%>
后来关闭后再打压果然不报错了,老大说这种这种问题很常见，不得不感叹经验很重要呀！
最后展示一下某个接口的打压情况：
现在打压出了接口的TPS，但是我还不知道要根据这个TPS怎么判断出使用几台服务器，周一把数据汇报给经理再确定。
和老大商讨后的结果：
根据现网10W认证用户可以算出：
就算用户增加到200W，算出来的 是：600多，但是打压出来的系统能力远不止这些，所以目前2台服务器就可以支撑了。
一个打压测试做完后不得不承认学到了很多啊，性能测试果然要学习很多知识、使用一些工具去辅助自己寻找问题，得到满意的分析结果。和老大交流会学到很多东西，有些东西是自己根本不知道的，所以跟牛人交流很重要，加油。
备注：如需转载，请私信联系我。
