记一次使用Jmeter的性能压测过程

最近在搞一个小项目，也是为春招准备准备，在写完基本的webserver后，部署到了阿里云服务器上，决定玩一玩压测，我的阿里云主机配置为学生机配置。
下面开始言归正传，目前Java压测中，比较大众的应该还是Jmeter，然后可以去到Jmeter的官网进行下载。
注意：一点要下载和自己JDK匹配的Jmeter版本，比如Jmeter4.0匹配jdk8和jdk9
，而Jmeter5.0则只匹配jdk8以上的（不包括jdk8！！）
下图为官网的描述：

官网首页只有最新版本，老版本链接在此

在这边下载，个人推荐选择binaries中的下载源进行下载，source中下载下来以后一运行Jmeter总是会报如下的错：

意思是说找不到ApacheJMeter.jar，迅速去安装目录里看看，在根目录和Jmeter的bin目录下都找不到这个jar（我起初以为是我网络或者下载器的问题，后来发现就是source这个下载源很有问题，至于sources我没有试过），所以就试了试binaries中的，我的操作系统是x64，win10，我选择下载的版本是下面的这个：

下载解压后，需要去配置一下子环境变量，否则的话，是启动不了的，环境变量网上有很多博客，可以自行百度一下，分别配置一下系统变量中的Path，Classpath再新建一个JMETER_HOME即可。
一般，对于启动后对话框一闪就消失的问题应该就是环境变量配置得问题（我遇到的是这种情况）
配置去Jmeter的bin目录启动Jmeter.bat（windows批处理文件）
，启动后是下面的样子：（一个终端，还有一个带GUI的系统）

接下来确保自己在服务器上的应用在后台正常运行，我的项目是springboot写的，直接在pom.xml加上maven的打包依赖，mvn clean，maven package打成jar，之后上传服务器，在服务器终端中使用命令：

nohup java -jar xxxxxxx.jar &

然后按回车，之后稍等一下，输入如下命令查看应用是否启动了，并且与此同时，在与jar同以目录下，会生成一个名为nohup.out的日志文件：

netstat -tunlp | grep 8090

发现服务已经启动，pid为7172，想要查看具体启动情况，可以使用cat命令查看nohup.out的内容

下一步就是在Jmeter中继续压测了，这里有四个点需要进行配置：

• 线程组：用来组装Jmeter发送请求的线程池
• Http请求，用来模拟压测中客户端对于接口的调用
• 查看结果树：可以查看结果集合，其中正确结果，失败结果均可以查询，而且会有一个返回值
• 聚合报告：反映性能的平均数，中位数，90线，95线，99线，以及
  对应TPS的数量，不清楚TPS的话看看这里：TPS与QPS

下面就开始了：
首先，英文不太好的盆友可以切换一下语言：

现在右键单击测试计划，添加一个线程组

线程组中常用的为下面三个配置：

比如这里就是让20个线程在10秒内完成启动并且每个线程循环执行1次。

下一步：添加Http请求，即对于自己想要做压力测试的接口进行请求配置

添加好了之后，对于一些属性做出配置：

注意，这里的keep-alive属性要打勾，目的是建立长链接，既然是在做压测，那么就不该把性能分散到频繁得链接建立上去，否则开销太大
接下来，右键单击http请求，分别添加结果树与聚合报告。

至此，就可以开始进行一个简单得压测了，我先对一个get请求进行简单得压测，点击开始：

这时如果没有保存过会跳出一个弹框提示你先保存自己的压测计划，保存之后就会执行了，起初我先将线程组设置成这样：

查看结果树：

进行了正常请求与数据响应，
查看聚合报告：

主要观察的指标为这两个，95%line是指返回百分之95的请求所消耗的时间，
可见，服务器并没有感受到任何压力，而且服务器还想笑，那下面我就要开始进一步测试了（注意：为了相对准确测出server端的性能，自己应该调整好每次增加的线程数以及对应的循环次数）

此处的过程省略500字儿…

来了来了他来了：
当我把线程数量加到下面这个样子：

结果再看看结果树：
起初还能正常请求，但是当线程都启动起来后：

这个时候基本是卡在这里了，看看聚合报告：这个错误率已经很高了，显然已经不再适合于服务用户了，而这个并发量说实话不算高，现在想想天猫双十一面对上亿并发量还能处理自如，确实是牛！

情况已经不太乐观了，那如果再上一波线程数呢？


发现，已经出现了很多的error，再查看聚合报告：

可以在服务器终端，使用top命令去查看cpu占用率，发现这个时候，cpu也飙得很高，并且mysqld，也就是数据库服服务，占用了大量CPU，所以看上去需要进一步做优化