JMeter性能压测

一：压力测试

• 压力测试考察当前软硬件环境下系统所能承受的最大负荷并帮助找出系统瓶颈所在。压测都 是为了系统在线上的处理能力和稳定性维持在一个标准范围内，做到心中有数。
• 使用压力测试，我们有希望找到很多种用其他测试方法更难发现的错误。有两种错误类型是: 内存泄漏，并发与同步。
• 有效的压力测试系统将应用以下这些关键条件:重复，并发，量级，随机变化。

压力测试可以模拟几百万用户同时访问，检测并发量，通过大并发的压力测试发现系统问题。

1.1 性能指标

• 响应时间（Response Time: RT） 响应时间指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的响 应结束，整个过程所耗费的时间。
• HPS（Hits Per Second） ：每秒点击次数，单位是次/秒。
• TPS（Transaction per Second）：系统每秒处理交易数，单位是笔/秒。
• QPS（Query per Second）：系统每秒处理查询次数，单位是次/秒。 对于互联网业务中，如果某些业务有且仅有一个请求连接，那么 TPS=QPS=HPS，一 般情况下用 TPS 来衡量整个业务流程，用 QPS 来衡量接口查询次数，用 HPS 来表 示对服务器单击请求。
• 无论 TPS、QPS、HPS,此指标是衡量系统处理能力非常重要的指标，越大越好，根据经 验，一般情况下：
  金融行业：1000TPS~50000TPS，不包括互联网化的活动
  保险行业：100TPS~100000TPS，不包括互联网化的活动
  制造行业：10TPS~5000TPS
  互联网电子商务：10000TPS~1000000TPS
  互联网中型网站：1000TPS~50000TPS
  互联网小型网站：500TPS~10000TPS
• 最大响应时间（Max Response Time） 指用户发出请求或者指令到系统做出反应（响应） 的最大时间。
• 最少响应时间（Mininum ResponseTime） 指用户发出请求或者指令到系统做出反应（响 应）的最少时间。
• 90%响应时间（90% Response Time） 是指所有用户的响应时间进行排序，第 90%的响
  应时间。
• 从外部看，性能测试主要关注如下三个指标
  吞吐量：每秒钟系统能够处理的请求数、任务数。
  响应时间：服务处理一个请求或一个任务的耗时。
  错误率：一批请求中结果出错的请求所占比例。

1.2 Apache JMeter

1）JMeter安装

https://jmeter.apache.org/download_jmeter.cgi

2）点击bin目录下的jmeter.bat文件
3）JMeter 压测示例
1.添加线程组


线程组参数详解：

• 线程数：虚拟用户数。一个虚拟用户占用一个进程或线程。设置多少虚拟用户数在这里 也就是设置多少个线程数。
• Ramp-Up Period(in seconds)准备时长：设置的虚拟用户数需要多长时间全部启动。如果 线程数为 10，准备时长为 2，那么需要 2 秒钟启动 10 个线程，也就是每秒钟启动 5 个 线程。
• 循环次数：每个线程发送请求的次数。如果线程数为 10，循环次数为 100，那么每个线 程发送 100 次请求。总请求数为 10*100=1000 。如果勾选了“永远”，那么所有线程会 一直发送请求，一到选择停止运行脚本。
• Delay Thread creation until needed：直到需要时延迟线程的创建。
• 调度器：设置线程组启动的开始时间和结束时间(配置调度器时，需要勾选循环次数为 永远)
• 持续时间（秒）：测试持续时间，会覆盖结束时间
• 启动延迟（秒）：测试延迟启动时间，会覆盖启动时间
• 启动时间：测试启动时间，启动延迟会覆盖它。当启动时间已过，手动只需测试时当前 时间也会覆盖它。
• 结束时间：测试结束时间，持续时间会覆盖它。

2.添加 HTTP 请求


3.添加监听器

4.启动压测&查看分析结果

结果分析：

• 有错误率同开发确认，确定是否允许错误的发生或者错误率允许在多大的范围内；
• Throughput 吞吐量每秒请求的数大于并发数，则可以慢慢的往上面增加；若在压测的机 器性能很好的情况下，出现吞吐量小于并发数，说明并发数不能再增加了，可以慢慢的 往下减，找到最佳的并发数；
• 压测结束，登陆相应的 web 服务器查看 CPU 等性能指标，进行数据的分析;
• 最大的 tps，不断的增加并发数，加到 tps 达到一定值开始出现下降，那么那个值就是 最大的 tps。
• 最大的并发数：最大的并发数和最大的 tps 是不同的概率，一般不断增加并发数，达到 一个值后，服务器出现请求超时，则可认为该值为最大的并发数。
• 压测过程出现性能瓶颈，若压力机任务管理器查看到的 cpu、网络和 cpu 都正常，未达
  到 90%以上，则可以说明服务器有问题，压力机没有问题。
• 影响性能考虑点包括： 数据库、应用程序、中间件（tomact、Nginx）、网络和操作系统等方面
• 首先考虑自己的应用属于 CPU 密集型还是 IO 密集型

1.3 JMeter Address Already in use 错误解决

windows 本身提供的端口访问机制的问题。
Windows 提供给 TCP/IP 链接的端口为 1024-5000，并且要四分钟来循环回收他们。就导致 我们在短时间内跑大量的请求时将端口占满了。 1.cmd 中，用 regedit 命令打开注册表
2.在 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 下，

• 1 .右击 parameters，添加一个新的 DWORD，名字为 MaxUserPort
• 2 .然后双击 MaxUserPort，输入数值数据为 65534，基数选择十进制（如果是分布式运 行的话，控制机器和负载机器都需要这样操作哦）

3 修改配置完毕之后记得重启机器才会生效 https://support.microsoft.com/zh-cn/help/196271/when-you-try-to-connect-from-tcp-ports-grea ter-than-5000-you-receive-t
TCPTimedWaitDelay：30

二：测试nginx对性能的影响

2.1 打开jmeter进行测试

• 将线程数修改为50，并且勾中永远，让其一直测试，除非手动停止

2.2 给nginx发送请求

给服务器的80端口发送请求，并添加如下汇总图

• 使用docker stats查看docker容器使用情况
  
  结论：nginx需要给其他服务频繁转发，所以使用消耗的线程多，内存小，cpu占用空间大

三：监控指标

3.1 中间件指标

• 当前正在运行的线程数不能超过设定的最大值。一般情况下系统性能较好的情况下，线 程数最小值设置 50 和最大值设置 200 比较合适。
• 当前运行的 JDBC 连接数不能超过设定的最大值。一般情况下系统性能较好的情况下， JDBC 最小值设置 50 和最大值设置 200 比较合适。
• ＧＣ频率不能频繁，特别是 FULL GC 更不能频繁，一般情况下系统性能较好的情况下， JVM 最小堆大小和最大堆大小分别设置 1024M 比较合适。

3.2 数据库指标

• SQL 耗时越小越好，一般情况下微秒级别。
• 命中率越高越好，一般情况下不能低于 95%。
• 锁等待次数越低越好，等待时间越短越好。

3.3 联合测试

• 中间件越多，性能损失越大，大多都损失在网络交互了；
• 业务：
  Db（MySQL 优化）
  模板的渲染速度（缓存）
  静态资源

四：优化吞吐量

4.1 nginx实现动静分离

1）以后所有的静态资源都放在nginx里面
2）规则：/static/***所有请求都由nginx直接返回
3）搬家静态资源（将静态资源直接转移到服务器里面）

• 进入到HTML路径下 cd /mydata/nginx/html
• 在HTML下新建static mkdir static
• 进入到static文件夹，并且将product的静态资源index复制进去（将本项目的静态资源删除）
• 在img,src,herf标签中加入/static/路径
  

4.2 修改服务器nginx的配置

1）进入到cd /mydata/nginx/conf/conf.d路径下
2）修改gulimail.conf文件 vi gulimail.conf

     location /static/ {
      root  /usr/share/nginx/html;
    }