jmeter压测、以及性能分析(需要登录的系统)---有图有真相、超详细

每个项目开发完成必然要经过各种测试，也会进行压测一下，判断开发完成的系统的可支撑并发量，我选用目前常用的jmeter,

最新版本下载地址：http://jmeter.apache.org/download_jmeter.cgi

下载完成解压，双击jmeter.bat即可启动(或者直接命令号启动)，如图：

启动后，

语言版本选择：

添加线程组：

配置http头信息：

正常登陆都带有cookie、token，这里配置

cookie配置：

添加值：

 

 

查看结果树：

汇总图：

添加一个测试接口请求：

填写参数和url如图：

线程组设置，为50个线程，循环2次：

1：线程数：并发数量，能跑多少量。具体说是一次存在多少用户同时访问
2：Rame-Up Period(in seconds):表示JMeter每隔多少秒发动并发。理解成准备时长：设置虚拟用户数需要多长时间全部启动。如果线程数是20，准备时长为10，那么需要10秒钟启动20个数量，也就是每秒钟启动2个线程。
3：循环次数：这个设置不会改变并发数，可以延长并发时间。总请求数=线程数*循环次数
4：调度器：设置压测的启动时间、结束时间、持续时间和启动延迟时间。
 

 

启动开始压测：

分析压测结果：

查看结果树：

查看汇总图：

红框结果解析：

Label：每个 JMeter 的 element（例如 HTTP Request）都有一个 Name 属性，这里显示的就是 Name 属性的值
#Samples：表示你这次测试中一共发出了多少个请求，如果模拟10个用户，每个用户迭代10次，那么这里显示100
Average：平均响应时间——默认情况下是单个 Request 的平均响应时间，当使用了 Transaction Controller 时，也可以以Transaction 为单位显示平均响应时间
Median：中位数，也就是 50％ 用户的响应时间
90% Line：90％ 用户的响应时间
Note：关于 50％ 和 90％ 并发用户数的含义，请参考下文
http://www.cnblogs.com/jackei/archive/2006/11/11/557972.html
Min：最小响应时间
Max：最大响应时间
Error%：本次测试中出现错误的请求的数量/请求的总数
Throughput：吞吐量——默认情况下表示每秒完成的请求数（Request per Second），当使用了 Transaction Controller 时，也可以表示类似 LoadRunner 的 Transaction per Second 数，
KB/Sec：每秒从服务器端接收到的数据量，相当于LoadRunner中的Throughput/Sec

压测后结果分析：
1：有错误率同开发确认，确定是否允许错误的发生或者错误率允许在多大的范围内；

2：Throughput吞吐量每秒请求的数大于并发数，则可以慢慢的往上面增加；若在压测的机器性能很好的情况下，出现吞吐量小于并发数，说明并发数不能再增加了，可以慢慢的往下减，找到最佳的并发数；

3：压测结束，·登陆相应的web服务器查看CPU等性能指标，进行数据的分析;:

4：最大的tps:不断的增加并发数，加到tps达到一定值开始出现下降，那么那个值就是最大的tps。

5：最大的并发数：最大的并发数和最大的tps是不同的概率，一般不断增加并发数，达到一个值后，服务器出现请求超时，则可认为该值为最大的并发数。
6：压测过程出现性能瓶颈，若压力机任务管理器查看到的cpu、网络和cpu都正常，未达到90%以上，则可以说明服务器有问题，压力机没有问题。:

7：通常影响性能考虑点包括：数据库、应用程序、中间件（tomact、Nginx）、网络和操作系统等方面
 

更为详细的解析可参考：https://www.cnblogs.com/opps/p/4538518.html、https://blog.csdn.net/github_27109687/article/details/71968662

 

提交的数据较多容易卡，这里遇到这个修改内存后不生效问题(jmeter5版本)，有大佬指定指点下，

修改的代码：

修改启动后：