2、全部页面加载时间 全部页面载入时间指从最初启动浏览开始，直到所有元素都被加载完成后，在2秒后仍然没有网络活动的时间。 0-2秒：用户体验最好，打分100 2-8秒：用户可以容忍，从第2秒开始，每超过1秒减5分 8-15秒：用户不能忍受，从第2秒开始，每超过1秒减5分
3、首字节时间 从开始加载到收到服务器返回数据的第一字节的时间 达标时间=DNS解析时间+创建连接时间+SSL认证时间+100ms. 比达标时间每慢10ms减1分. 0-1秒：用户体验最好 1-2秒：用户可以容忍 2-3秒：用户不能容忍
4、使用长连接 连接视图展现了页面加载过程中创建的（keepalive）连接，以及通过每个连接所加载的资源。
5、DNS时间 进行域名解析所需要的时间 0-50毫秒 100分 50-500毫秒 一般，可能会影响用户体验，从50毫秒开始，每增加10毫秒则减去2分 500毫秒以上，严重影响⽤用户的网页体验，从50毫秒开始，每增加10毫秒则减去2分
6、TCP时间 客户端建立连接的时间 0-100毫秒 100分 100-500毫秒，一般，可能会影响用户体验，从100毫秒开始，没增加10毫秒，减去1分 500毫秒以上，严重影响⽤用户的网页体验，从100毫秒开始，每增加10毫秒，减去1分
7、HTTP网页打分 页面渲染、下载速度、页面流畅度
8、综合评分 以上评分的加权 计算值=全部页面载入时间评分*0.2+首字节时间评分*0.2+使用了长连接*0.1+DNS时间评分*0.2+TCP时间评分*0.2+HTTP网页评分*0.1
9、其他一些测量指标 请求时间 定义：所谓的请求时间是指用户从三次握手到最后一次请求发出的这一段时 间，这个时间可以用于定位网络问题。 网络丢包率 定义：当前的网络的丢包情况统计。 网络时延 定义：当前网络的时延。包括RTTc和RTTs。 RTTc 用户到探针的传输时延 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个用户访问动态页面
并发线程数:测试时同时访问被测系统的线程数。 注意,由于测试过程中, 每个线程都是以 尽可能快的速度发请求, 与实际用户的使用有极大差别, 所以, 此数据不等同于实际使用时 的并发用户数。 每次时间间隔:测试线程发出一个请求, 并得到被测系统的响应后, 间隔多少时间发出下一 次请求。 平均响应时间:测试线程向被测系统发请求,所有请求的响应时间的平均值。