一、分析系统性能的指标

1.吞吐量指标：TPS、QPS      请求--响应

TPS：T（transaction）每秒钟处理的请求响应数。多个事务操作【涉及数据库数据变更操作】

QPS：Q（query）【不涉及数据库变更操作】

吞吐量低：系统每秒处理的请求数量有限

2.响应时间（发送请求到收到请求的响应耗时）

RT(responseTime)：关系到用户体验

3.成功率

在高并发状态下，程序是否出现处理失败的情况

高并发状态下，偶尔出现失败，系统是可以承受的。但是需要分场景：有些场景如：充值，对成功率要求很高；如查询，对成功率要求不太高

二、jmeter性能测试结果报告

1.聚合报告

如下图：进行分析

系统在2分钟之内有7w次请求，80%都出错了，说明有6w次请求都出错了，接下来需要在【察看结果树】中查看出错原因是什么？

2.察看结果树

出现错误：Address already in use：connect

原因：网络请求发起的时候，服务器需要一个固定端口接收数据，客户端向服务器发起请求，需要占用客户端端口，就意味着端口号可能不够，不够时存在端口抢占情况，端口被占用，连接被使用

那么如何解决这个错误问题呢？

单台机器能够发起的请求数量是有限的，那么要模拟高并发可以使用【jmeter集群压测】。使用jmeter分布式架构，构建一个jmeter集群

1.在多个服务器上安装部署jmeter

2.修改配置文件（在jmeter的bin目录下修改 jmeter.properties文件，添加下面两行内容）

3.启动jmeter服务器：在jmeter的bin目录下执行命令【./jmeter-server -Djava.rmi.server.hostname=ip地址】启动 并指定服务器访问的IP地址

远程jmeter服务启动好了，那么如何通过本地windows系统中的jmeter脚本执行呢？

4.修改本地windows中jmeter/bin 下面的jmeter.properties中的remote_hosts，配置远程连接的jmeter服务器ip+port

5.在本地jmeter界面运行脚本时不能直接点击工具栏的启动按钮，需要点击【运行--远程启动--选择远程启动的jmeter服务器】

这样就可以进行jmeter远程集群压测了

说明：性能测试对测试脚本的执行机器是有配置要求的。如果要进行实际压测，需要确定jmeter执行机的配置，尽可能模拟现场正式环境，如果配置达不到，可使用多台执行机进行集群测试。

三、性能分析

如何根据聚合报告和察看结果树进行性能分析？

问：系统是否能处理5000并发？ 能处理多少并发？

——绝对并发：同一时间有多少请求给服务器处理（1s？1ms？还有更小单位，不好确定）

        如：实时聊天室，同时在线人数，这时使用绝对并发----网络长连接

——相对并发：（我们常说的并发指相对并发）一段时间内服务器需要处理的并发（1s）

        web应用基本95%以上都是http请求【请求/响应--结束，短连接】

能处理的最大并发量 约等于 最大吞吐量

如何知道系统最大的吞吐量呢？（系统瓶颈）

需要使用jmeter趋势图进行分析，在线程组（右键）---添加---监听器---jp@gc - Active Threads Over Time————线程的变化

                                                                                                           ---jp@gc - Response Times Over Time————响应时间的变化

                                                                                                           ---jp@gc - Transactions per Second————吞吐量的变化

将上面两个图进行对比分析：初期--吞吐量随着并发量（线程数）的增加而增加；吞吐量到达一定值后不再增加，趋于平稳~~~

如上：在24s时系统吞吐量出现拐点，到达峰值1800/s，即系统可以处理的最大并发数=1800。

分析性能瓶颈：系统并发达到1800的原因？————服务器原因（CPU、内存、磁盘、网络）、代码原因、系统架构（nginx集群）、数据库原因？ 需要进一步学习~~~~~