1. Page load time
The time from when the page starts to load to when the page onload event fires. Generally speaking, the onload trigger means that the CSS, JS, and image resources directly referenced by HTML have been fully loaded.
2. Full page load time
Total page load time refers to the time from the initial start of browsing until all elements are loaded, and there is still no network activity after 2 seconds.
0-2 seconds: the best user experience, score 100
2-8 seconds: the user can tolerate it, starting from the second second, every time it exceeds 1 second, 5 points will be deducted
8-15 seconds: the user can't stand it, starting from the second second, every time it exceeds 1 second, 5 points will be deducted
3. First byte time
The time from the start of loading to the receipt of the first byte of data returned by the server
Time to meet the standard = DNS resolution time + time to create a connection + SSL authentication time + 100ms. Decreases 1 point for every 10ms slower than the time to meet the standard.
0-1 seconds: the best user experience
1-2 seconds: User can tolerate
2-3 seconds: User can't tolerate it
4. Use a long connection
The connections view shows the (keepalive) connections created during page load, and the resources loaded through each connection.
5. DNS time
Time required for domain name resolution
0-50 ms 100 minutes
50-500 milliseconds is generally, may affect the user experience, start from 50 milliseconds, and subtract 2 points for every 10 milliseconds
More than 500 milliseconds, seriously affecting the user's web page experience, starting from 50 milliseconds, and subtracting 2 points for every 10 milliseconds
6. TCP time
The time the client established the connection
0-100 ms 100 minutes
100-500 milliseconds, generally, may affect the user experience, starting from 100 milliseconds, no increase of 10 milliseconds, minus 1 point
More than 500 milliseconds, which seriously affects the user's web page experience. Starting from 100 milliseconds, every 10 milliseconds increases, minus 1 point
7. HTTP web page scoring
Page rendering, download speed, page fluency
8. Comprehensive score
Weighting of the above ratings
Calculated value = total page load time score * 0.2 + first byte time score * 0.2 + long connection used * 0.1 + DNS time score * 0.2 + TCP time score * 0.2 + HTTP page score * 0.1
9. Some other metrics
request time
Definition: The so-called request time refers to the period from the three-way handshake to the last request issued by the user
time, this time can be used to locate network problems.
network packet loss rate
Definition: Statistics of packet loss in the current network.
network delay
Definition: The delay of the current network. Includes RTTc and RTTs.
RTTc
User-to-probe transmission delay
RTTs
探针到服务器的传输时延
可以关联的其他指标
受影响的用户数
所谓受影响，即当该业务的某个指标比较差时，有多少个用户受到影响。通过
这个指标，可以进而得到具体受到影响的用户是哪些。
受影响的站点数
即当网络出现问题，或者是服务器出现问题时，有多少个站点受到影响。通过
这个指标，可以进而得到具体受到影响的站点是哪些。
还有什么指标呢？
简单的说一个Web请求的处理包括以下步骤：
（1）客户发送请求
（2）web server 接受到请求，进行处理；
（3）web server 向DB获取数据；
（4）web server生成用户的object(页面)，返回给用户。给客户发送请求开始到最后一个字节的时间称为响应时间(第三步不包括在每次请求处理中）。
1.事务Transaction
2.请求响应时间
3.事务响应时间
事务可能由一系列请求组成,事务的响应时间主要是针对用户而言,属于宏观上的概念，是为了向用户说明业务响应时间而提出的.
例如:跨行取款事务的响应时间就是由一系列的请求组成的.
事务响应时间是直接衡量系统性能的参数.
4.并发用户数
并发一般分为2
种情况。一种是严格意义上的并发，
即所有的用户在同一时刻做同一件事情或者操作，这种操作一般指做同一类型的业务。比如在信用卡审批业务中，一定数目的拥护在同一时刻对已经完成的审批业务进行提交；还有一种特例，即所有用户进行完全一样的操作，例如在信用卡审批业务中，所有的用户可以一起申请业务，或者修改同一条记录。
另外一种并发是广义范围的并发。这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或者操作可以是相同的，也可以是不同的。对整个系统而言，仍然是有很多用户同时对系统进行操作，因此也属于并发的范畴。
可以看出，后一种并发是包含前一种并发的。而且后一种并发更接近用户的实际使用情况，因此对于大多数的系统，只有数量很少的用户进行“严格意义上的并发”。对于WEB性能测试而言，这2种并发情况一般都需要进行测试，通常做法是先进行严格意义上的并发测试。严格意义上的用户并发一般发生在使用
比较频繁的模块中，尽管发生的概率不是很大，但是一旦发生性能问题，后果很可能是致命的。严格意义上的并发测试往往和功能测试
关联起来，因为并发功能遇到异常通常都是程序问题，这种测试也是健壮性和稳定性测试的一部分。
用户并发数量：关于用户并发的数量，有2种常见的错误观点。
一种错误观点是把并发用户数量理解为使用系统的全部用户的数量，理由是这些用户可能同时使用系统；还有一种比较接近正确的观点是把在线用户数量理解为并发用户数量。实际上在线用户也不一定会和其他用户发生并发，例如正在浏览网页的用户，对服务器没有任何影响，但是，在线用户数量是计算并发用户数量的主要依据之一。
5.吞吐量
指的是在一次性能测试过程中网络上传输的数据量的总和
.吞吐量/传输时间,就是吞吐率.
6.TPS
7.点击数PV
每秒钟用户向WEB服务器提 交的HTTP请求数.这个指标是WEB应用特有的一个指标:WEB 应用是"请求-响应"模式,用户发出一次申请,服务器就要处理一次,所以点击是WEB
应用能够处理的交易的最小单位.如果把每次点击定义为一个交易,点击率和TPS就是一个概念.容易看出,点击率越大,对服务器的压力越大.点击率只是一个性能参考指标,重要的是分析点击时产生的影响。需要注意的是,这里的点击并非指鼠标的一次单击操作,因为在一次单击操作中,客户端可能向服务器发出多个HTTP请求.
8.资源利用率
性能项 命令 指标
CPU限制 vmstat 当%user+%sys超过80%时
磁盘I/O限制 Vmstat 当%iowait超过40%(AIX4.3.3或更高版本)时
应用磁盘限制 Iostat 当%tm_act超过70%时
虚存空间少 Lsps，-a 当分页空间的活动率超过70%时
换页限制 Iostat, stat 虚存逻辑卷%tm_act超过I/O(iostat)的30%，激活的虚存率超过CPU数量(vmstat)的10倍时
系统失效 Vmstat, sar 页交换增大、CPU等待并运行队列
性能项 资源 评价
CPU占用率 70% 好
85% 坏
90%+ 很差
磁盘I/0 <30% 好
<40% 坏
<50%+ 很差
网络 <30%带宽 好
运行队列 <2*CPU数量 好
内存 没有页交换 好
每个CPU每秒
10个页交换 坏
更多的页交换 很差
测试方案示例
静态和动态页面,静态页面施加 1000、动态页面施加 100和 200个用户,用 LoadRunner 11工具测试,创建相关操作脚本 , 设计测试场景,运行测试场景。
测试过程按两个步骤进行,即静态页面和动态页面两个页面的压力测试:
单独场景压力测试:针对单个页面进行压力测试,得出系统瓶颈。
测试场景示例
1. 静态页面测试场景
设计 1000个用户分别访问 GV 静态页面。
加压方案:每 15s 增加 20个用户,直到增加到 1000个。
减压方案:每 15s 停止 20个用户,直到全部停止。
2. 动态页面测试场景(一)
设计 100个用户分别访问 GV 动态页面。
加压方案:每 30s 增加 50个用户,直到增加到 100个。
减压方案:每 30s 停止 50个用户,直到全部停止。
3. 动态页面测试场景(二) (未记录)
设计 200个用户分别访问 GV 动态页面。
加压方案:每 30s 增加 50个用户,直到增加到 100个。
减压方案:每 30s 停止 50个用户,直到全部停止。
测试用例示例
1. 1000个用户访问静态静态页面
2. 100个用户访问动态页面
并发线程数:测试时同时访问被测系统的线程数。 注意,由于测试过程中, 每个线程都是以 尽可能快的速度发请求, 与实际用户的使用有极大差别, 所以, 此数据不等同于实际使用时 的并发用户数。
每次时间间隔:测试线程发出一个请求, 并得到被测系统的响应后, 间隔多少时间发出下一 次请求。
平均响应时间:测试线程向被测系统发请求,所有请求的响应时间的平均值。