本部分内容：
一些名词
请求响应时间：
事务响应时间：
吞吐量：
吞吐率（Throughput）：
TPS（Transaction Per Second）：
点击率（Hit Per Second）：
资源利用率：
jmeter得出被测服务器的资源利用率：
如何让第三方监控器的结果用命令行模式执行搜集？
为什么要用命令模式进行性能测试？
摘要报告（Summary Report）：
聚合报告：
90%Line的理解：

一些名词

请求响应时间：

请求响应时间是指从客户端发出请求到得到响应的整个过程的时间。这个过程从客户端发出一个请求开始计时，到客户端接收到从服务器端返回的响应结果计时结束。在某些工具中，请求响应时间通常会被称为"TTLB"，即"Time to last byte"，意思是从发送一个请求开始，到客户端接收到最后一个字节的响应为止所耗费的时间。请求响应时间的单位一般为“秒”或“毫秒”。

事务响应时间：

事务可能由一系列请求组成，事物的响应时间主要针对用户而言，属于宏观上的概念，是为了向用户说明业务响应时间而提出来的。例如：跨行取款事物的响应时间就是由一系列的请求组成的。事物响应时间和业务吞吐率都是直接衡量系统性能的参数。

吞吐量：

指在一次性能测试过程中网络上传输的数据量的总和。吞吐量/传输时间，就是吞吐率。

吞吐率（Throughput）：

下载和上传速度即吞吐率

通常用来指单位时间内网络上传输的数据量，也可以指单位时间内处理的客户端请求数量，是衡量网络性能的重要指标。

但是从用户或业务角度来看，吞吐率也可以用“请求数/秒”或“页面数/秒”、“业务数/小时或天”、“访问人数/天”、“页面访问量/天”来衡量。例如在银行卡审批系统中，可以用“千件/每小时”来衡量系统的业务处理能力。

TPS（Transaction Per Second）：

每秒钟系统能够处理的交易或事务的数量。它是衡量系统处理能力的重要指标。TPS是LoadRunner中重要的性能参数指标。

点击率（Hit Per Second）：

每秒钟用户向Web服务器提交的HTTP请求数。这个指标是Web应用特有的一个指标：Web应用是“请求-响应”模式，用户发出一次申请，服务器就要处理一次，所以“点击”是Web应用能够处理交易的最小单位。如果把每次点击定义为一次交易，点击率和TPS就是一个概念。不难看出，点击率越大，对服务器的压力也越大。点击率只是一个性能参考指标，重要的是分析点击时产生的影响。

需要注意的是，这里的点击不是指鼠标的一次“单击”操作，而是在一次“单击”操作中，客户端可能向服务器发出多个HTTP请求。

资源利用率：

资源利用率指的是对不同系统资源的使用程度，例如服务器的CPU利用率、磁盘利用率等。资源利用率是分析系统性能指标而改善性能的主要依据，因此，它是Web性能测试工作的重点。

资源利用率主要针对Web服务器、操作系统、数据库服务器、网络等，是测试和分析瓶颈的主要参数。在性能测试中，要根据需求采集具体的资源利用率参数来进行分析。

jmeter如何得出 请求响应时间--事务响应时间：通过聚合报告或者是摘要报告中可以查看

ip_image002.jpeg

jmeter如何查看吞吐量和吞吐率：吞吐量可以通过下图摘要报告中的这两项相加可以得出

ip_image004.jpeg

吞吐量可以通过摘要报告的下面一项查看

ip_image006.jpeg

JMETER如何查看TPS：

ip_image008.jpeg

该列可以通过平均事务响应时间和定时器的时间累加,遇到min就需要累加

jmeter得出被测服务器的资源利用率：

1、进入https://jmeter-plugins.org/wiki/PerfMonAgent/下载ServerAgent-2.2.1.zip，把该压缩包在被测服务器上解压，解压后在dos命令窗口运行startAgent.sh命令，默认使用4444端口

2、在Jmeter工具端输入telnet 服务器ip 4444 然后输入test ,查看被测服务器是否有收到相应信息，收到表示连接正常，如果连接异常检查防火墙等原因。

3、在Jmeter控制机添加一个PerfMon Metrics Collector监听器，点击运行即可获取。

如何让第三方监控器的结果用命令行模式执行搜集？

第一步，在脚本中增加第三方监控器，不需要添加自带的监控器

第二步，在第三方监控器中，配置一个保存测试结果的路径

ip_image010.jpeg

备注：jtl文件在生成过程中是一个追加的操作，而不是覆盖。所以要及时更换文件名称保存不同的测试结果

为什么要用命令模式进行性能测试？

     命令窗口运行没有Jmeter界面，通过DOS命令窗口运行场景。用纯命令方式运行Jmeter是因为Jmeter可视化界面及监听器动态展示结果都比较消耗负载机资源，在大并发情况下GUI方式往往会导致负载机资源紧张，会对性能结果产生影响。

这个影响不是指被测系统的性能受到影响，而是指负载机的性能受到影响，导致负载量上不去，比如命令模式100个线程可产生100TPS的负载，而GUI方式只产生80TPS的负载。所以推荐进行性能测试的时候，使用命令方式来运行测试计划。

对比GUI图形化模式和命令模式的CPU

摘要报告（Summary Report）：

ip_image012.jpeg

Label：取样器名称（或者是事务名）。

Samples：取样器运行次数（提交了多少笔业务）。

Average：请求（事务）的平均响应时间，单位为毫秒。

Min：请求的最小响应时间，单位为毫秒。

Max：请求的最大响应时间，单位为毫秒。

Std.Dev：响应时间的标准方差。

Error%：事务错误率。

Throughput：吞吐率（TPS）。

KB/sec：每秒数据包流量，单位是KB。

Avg.Bytes：平均数据流量，单位是Byte。

聚合报告：

ip_image014.jpeg

聚合报告中大部分字段与Summary Report一致，不再重复介绍，其它说明如下：

Median：响应时间中间值，指 50％请求的响应时间。

90%Line：90％ 请求的响应时间

95%Line：95％ 请求的响应时间

99%Line：99％ 请求的响应时间

标准方差的理解：

1.数据分布离平均值越近，标准方差越小；数据分布离平均值越远，标准方差越大。

2.标准方差为0，意味着数列中每一个数都相等。

3.序列中每一个数都加上一个常数，标准方差保持不变的

所以，在查看测试报告时，标准方差越小，表示系统越趋于稳定。

举例：

446 898 667 456 578 623 992 964 1057

平均值是664

90%Line的理解：

表示90%请求的响应时间，服务器的响应都维持在某个值附近。“Average”值对于平均事务响应时间变动趋势很大的情况统计就不准确了，比如有三个时间：1秒、5秒、12秒，则平均时间为6秒，而另外一种情况：5秒、6秒、7秒，平均时间也为6秒，显然第二种比第一种要稳定多了。所以，如果整体趋势比较稳定，取90%Line与Average区别不大。

举例：

446 898 667 456 578 623 992 964 1057

50%line： 9*0.5 4.5 9-4.5=4.5 去掉4个或5个

排序： 446 456 578 623 667 898 964 992 1057

去掉4个后： 578 623 667 898 964

求平均值: (578+623+667+898+964)/5

结论：标准方差越大，就不能使用平均值作为事务响应时间而要取90%LINE等

jmeter生成网页格式的性能测试报告

-e -o 空目录

举例：

jmeter -n -t "C:\Jmeter_script\T93\T93login_BBS_Random.jmx" -l "C:\Jmeter_script\T93\result\res003.jtl" -e -o "C:\Jmeter_script\T93\res001"

可以生成如下图所示：

ip_image016.jpeg