指标的基本概念
1、事物（Transaction）
在web性能测试中，一个事物表示一个“从用户发送请求->web server接收到请求，进行处理->web server 向数据库获取数据->生成用户的object(页面)，返回给用户”的过程，一般的响应时间都是针对事物而言的。
2、请求响应时间
请求响应时间指的是从客户端发起的一个请求开始，到客户端接收到从服务器端返回的响应结束，这个过程所耗费的时间，在某些工具中，响应通常被称为“TTLB”，即“Time To Last Byte"，意思是从发起一个请求开始，到客户端接收到最后一个字节所耗费的时间，响应时间一般为”秒“或者”毫秒“。一个公式可以表示：响应时间=网络响应时间+应用程序响应时间。
（1）在1秒钟之内，页面给予用户响应并有所显示，可认为是“很不错的”；
（2）在1~2秒钟之内，页面给予用户响应并有所显示，可认为是“好的”；
（3）在2~3秒钟内，页面给予用户响应并有所显示，可认为是“勉强接受的”；
（4）超过3秒就让人有点不耐烦了，用户很可能不会继续等待下去；
3、事物响应时间
事物可能由一系列请求组成，事物的响应时间主要是针对用户而言，属于宏观上的概念，是为了向用户说明业务响应时间而提出的。例如：跨行取款事物的响应时间就是由一系列的请求组成的。事物响应时间是直接衡量系统性能的参数。
4、并发用户数
并发一般分为2种情况，一种是严格意义上的并发，即所有的用户在同一时刻做同一件事情或操作，这种操作一般指做同一类型的业务。比如在信用卡审批业务中，一定数目的用户在同一时刻对已经完成审批的业务进行提交；还有一种特例，即所有用户进行完全一样的操作，例如在信用卡审批业务中，所有的用户可以一起申请业务，或者修改同一条记录。
另外一种并发是广义范围的并发。这种并发与前一种的区别是，尽管多个用户对系统发出了请求或进行了操作，但是这些请求或者操作可以是相同的，也可以是不同的。对整个系统而言，仍然是有很多用户同时对系统进行操作，因此也属于并发的范畴。
可以看出，后一种并发是包含前一种并发的。而且后一种并发更接近用户的实际使用情况，因此对于大多数的系统，只有数量很少的用户进行“严格意义上的并发”。对于WEB性能测试而言，这2种并发情况一般都需要进行测试，通常做法是先进行严格意义上的并发测试。严格意义上的用户并发一般发生在使用比较频繁的模块中，尽管发生的概率不是很大，但是一旦发生性能问题，后果很可能是致命的。严格意义上的并发测试往往和功能测试关联起来，因为并发功能遇到异常通常都是程序问题，这种测试也是健壮性和稳定性测试的一部分。
用户并发数量：关于用户并发的数量，有2种常见的错误观点。 一种错误观点是把并发用户数量理解为使用系统的全部用户的数量，理由是这些用户可能同时使用系统；还有一种比较接近正确的观点是把在线用户数量理解为并发用户数量。实际上在线用户也不一定会的和其他用户发生并发，例如正在浏览网页的用户，对服务器没有任何影响，但是，在线用户数量是计算并发用户数量的主要依据之一。
5、吞吐量
指的是在一次性能测试过程中网络上传输的数据量的总和。吞吐量÷传输时间，就是吞吐率。
6、TPS（Transaction per second）
每秒钟系统能够处理的交易或者事物的数量。它是衡量系统处理能力的重要指标。
7、点击率
每秒钟用户向WEB服务器提交的HTTP请求数。这个指标是WEB应用特有的一个指标:WEB应用是"请求-响应"模式,用户发出一次申请,服务器就要处理一次,所以点击是WEB应用能够处理的交易的最小单位。如果把每次点击定义为一个交易,点击率和TPS就是一个概念。容易看出,点击率越大,对服务器的压力越大。点击率只是一个性能参考指标,重要的是分析点击时产生的影响。需要注意的是,这里的点击并非指鼠标的一次单击操作,因为在一次单击操作中,客户端可能向服务器发出多个HTTP请求。
8、资源利用率
指的是对不同的系统资源的使用程度,例如服务器的CPU利用率,磁盘利用率等.资源利用率是分析系统性能指标进而改善性能的主要依据,因此是WEB性能测试工作的重点.
资源利用率主要针对WEB服务器,操作系统,数据库服务器,网络等,是测试和分析瓶颈的主要参考.在WEB性能测试中,更根据需要采集相应的参数进行分析。
通用指标（指Web应用服务器、数据库服务器必需测试项)
| 指标 | 说明 |
|---|---|
| ProcesserTime | 服务器CPU占有率，一般平均达到70%时，服务就接近饱和 |
| Memory Available Mbyte | 用内存数，如果测试时发现内存有变化情况也要注意，如果是内存泄露则比较严重 |
| Physicsdisk Time | 物理磁盘读写时间情况 |
Web服务器指标
| 指标 | 说明 |
|---|---|
| Requests Per Second（Avg Rps | 平均每秒钟响应次数＝总请求时间 / 秒数 |
| Avg time to last byte per terstion （mstes | 平均每秒业务脚本的迭代次数 ,有人会把上面那个混淆 |
| Successful Rounds | 成功的请求 |
| Failed Requests | 失败的请求 |
| Successful Hits | 成功的点击次数 |
| Failed Hits | 失败的点击次数 |
| Hits Per Second | 每秒点击次数 |
| Successful Hits Per Second | 每秒成功的点击次数 |
| Failed Hits Per Second | 每秒失败的点击次数 |
| Attempted Connections | 尝试链接数 |
数据库服务器性能指标
| 指标 | 说明 |
|---|---|
| User 0 Connections | 用户连接数，也就是数据库的连接数量 |
| Number of deadlocks | 数据库死锁 |
| Butter Cache hit | 数据库Cache的命中情况 |
系统的瓶颈定义
| 性能项 | 命令 | 指标 |
|---|---|---|
| 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个页交换 更多的页交换 |
好 坏 很差 |
接口性能要求
http接口性能要求
该要求不包括文件上传 等重量级接口
| 指标名称 | 要求 | 优先级 | 备注 |
|---|---|---|---|
| 响应时间 | 500 millisecond | 1 | |
| 请求成功率 | 99% | 2 | |
| TPS | 在满足预期要求的情况下服务器状态稳定，单台服务器TPS要求在1000左右 | 3 | |
| 资源使用率 | 要求在TPS正常幅度的情况下资源使用率幅度平稳，服务器状态平稳 | 3 | 要求接口的内部实现不能占用太多资源 |
| 数据库死锁 | 0，要求接口在使用过程中不会造成数据库死锁 | 1 | |
| CPU限制 | 要求接口在使用过程中不会出现大量的计算 | 3 | |
| 内存 | 要求接口在使用过程中不会出现内存大量消耗的情况 | 3 |
dubbo接口性能要求
| 指标名称 | 要求 | 优先级 | 备注 |
|---|---|---|---|
| 响应时间 | 500 millisecond | 1 | |
| 请求成功率 | 99% | 2 | |
| TPS | 在满足预期要求的情况下服务器状态稳定，单台服务器TPS要求在1000左右 | 3 | |
| 资源使用率 | 要求在TPS正常幅度的情况下资源使用率幅度平稳，服务器状态平稳 | 3 | 要求接口的内部实现不能占用太多资源 |
| 数据库死锁 | 0，要求接口在使用过程中不会造成数据库死锁 | 1 | |
| CPU限制 | 要求接口在使用过程中不会出现大量的计算 | 3 | |
| 内存 | 要求接口在使用过程中不会出现内存大量消耗的情况 | 3 |
原文链接：http://blog.csdn.net/strawbingo/article/details/46458959