1 引言
1.1 编写目的
本文总结提炼性能测试相关项目实施经验，规范使用性能测试进行性能测试系统技术指标，规范技术测试结果评价，统一性能测试技术测试质量度量。应用系统技术质量度量指标范围广泛，本文难以涵盖全部。用常用指标来进行说明，其他未说明指标将在后续测试工作中继续补充和完善本指标体系。
1.2 适用对象和范围
本指标适用于使用性能测试进行性能测试项目技术质量评价依据。预期读者为测试管理人员、测试实施人员、技术支持人员、项目管理人员等系统技术质量相关人员。
2 系统性能指标
2.1 业务指标
业务指标主要包括并发用户数、响应时间、处理能力，这三个指标有一定的关系的，具体可参照：《并发用户数与TPS关系》
2.1.1 交易响应时间
2.1.1.1 定义及解释
响应时间指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的响应结束，整个过程所耗费的时间。在性能检测中一般以测试环境中压力发起端至服务器返回处理结果的时间为计量，单位一般为秒或毫秒,该时间不同于模拟真实环境的用户体验时间。
平均响应时间：指系统稳定运行时间段内，同一交易的平均响应时间。一般而言，交易响应时间均指平均响应时间。
平均响应时间指标值应根据不同的交易分别设定，一般情况下，分为复杂交易响应时间、简单交易响应时间、特殊交易响应时间。其中，特殊交易响应时间的设定必须明确该交易在响应时间方面的特殊性。
2.1.1.2 简称
Response Time: RT
2.1.1.3 标准
不同行业不同业务可接受的响应时间是不同的，一般情况，对于在线实时交易：
?互联网企业：500毫秒以下，例如淘宝业务10毫秒左右。
?金融企业：1秒以下为佳，部分复杂业务3秒以下。
?保险企业：3秒以下为佳。
?制造业：5秒以下为佳。
对于批量交易：
?时间窗口：不同数据量结果是不一样的，大数据量的情况下，2小时内完成。
2.1.2 系统处理能力
2.1.2.1 定义及解释
系统处理能力是指系统在利用系统硬件平台和软件平台进行信息处理的能力。
系统处理能力通过系统每秒钟能够处理的交易数量来评价，交易有两种理解：一是业务人员角度的一笔业务过程；二是系统角度的一次交易申请和响应过程。前者称为业务交易过程，后者称为事务。两种交易指标都可以评价应用系统的处理能力。一般的建议与系统交易日志保持一致，以便于统计业务量或者交易量。系统处理能力指标是技术测试活动中重要指标。
2.1.2.2 简称
一般情况下，用以下几个指标来度量：
?HPS（Hits Per Second）：每秒点击次数，单位是次/秒。
?TPS（Transaction per Second）：系统每秒处理交易数，单位是笔/秒。
?QPS（Query per Second）：系统每秒处理查询次数，单位是次/秒。
对于互联网业务中，如果某些业务有且仅有一个请求连接，那么TPS=QPS=HPS，一般情况下用TPS来衡量整个业务流程，用QPS来衡量接口查询次数，用HPS来表示对服务器点击请求。
2.1.2.3 标准
无论TPS、QPS、HPS,此指标是衡量系统处理能力非常重要的指标，越大越好，根据经验，一般情况下：
?金融行业：1000TPS~9000TPS
?保险行业：100TPS~1000TPS
?制造行业：10TPS~50TPS
?互联网电子商务：10000TPS~100000TPS,例如天猫5万TPS
?互联网中型网站：100TPS~500TPS
?互联网小型网站: 50TPS~100TPS
2.1.3 并发用户数
2.1.
3.1 定义及解释
并发用户数指在同一时刻内，登录系统并进行业务操作的用户数量。
并发用户数对于长连接系统来说最大并发用户数即是系统的并发接入能力。对于短连接系统而言最大并发用户数并不等于系统的并发接入能力，而是与系统架构、系统处理能力等各种情况相关。
在测试中，采用虚拟用户来模拟现实中用户进行业务操作。
2.1.
3.2 简称
Virtual User: VU
2.1.
3.3 标准
一般情况下，性能测试是将系统处理能力容量测出来，而不是测试并发用户数，除了服务器长连接可能影响并发用户数外，系统处理能力不受并发用户数影响，可以用最小的用户数将系统处理能力容量测试出来，也可以用更多的用户将系统处理能力容量测试出来。
2.1.4 错误率
2.1.4.1 定义及解释
错误率指系统在负载情况下，失败交易的概率。错误率＝(失败交易数/交易总数)*100%。稳定性较好的系统，其错误率应该由超时引起，即为超时率。
2.1.4.2 简称
Failure Ratio: FR
2.1.4.3 标准
不同系统对错误率的要求不同，但一般不超出千分之六，即成功率不低于99.4%
2.2 资源指标
2.2.1 CPU
2.2.1.1 定义及解释
中央处理器是一块超大规模的集成电路，是一台计算机的运算核心（Core）和控制核心（Control Unit）。它的功能主要是解释计算机指令以及处理计算机软件中的数据。CPU Load: 系统正在干活的多少的度量，队列长度。系统平均负载。
2.2.1.2 简称
Central Processing Unit：CPU
2.2.1.3 标准
CPU指标主要指的CPU利用率，包括用户态(user)、系统态(sys)、等待态(wait)、空闲态(idle)。CPU 利用率要低于业界警戒值范围之内，即小于或者等于75%;CPU sys%小于或者等于30%, CPU wait%小于或者等于5%。
单核CPU也需遵循上述指标要求。
CPU Load要小于CPU 核数。
2.2.2 Memory
2.2.2.1 定义及解释
内存是计算机中重要的部件之一，它是与CPU进行沟通的桥梁。计算机中所有程序的运行都是在内存中进行的，因此内存的性能对计算机的影响非常大。
2.2.2.2 简称
Memory就是内存的简称。
2.2.2.3 标准
现代的操作系统为了最大利用内存，在内存中存放了缓存，因此内存利用率100%并不代表内存有瓶颈，衡量系统内有有瓶颈主要靠SWAP（与虚拟内存交换）交换空间利用率，一般情况下，SWAP交换空间利用率要低于70%,太多的交换将会引起系统性能低下。
2.2.3 磁盘吞吐量
2.2.
3.1 定义及解释
磁盘吞吐量是指在无磁盘故障的情况下单位时间内通过磁盘的数据量。
2.2.
3.2 简称
Disk Throughput.
2.2.
3.3 标准
磁盘指标主要有每秒读写多少兆，磁盘繁忙率，磁盘队列数，平均服务时间，平均等待时间，空间利用率。
其中磁盘繁忙率是直接反映磁盘是否有瓶颈的的重要依据，一般情况下，磁盘繁忙率要低于70%。
2.2.4 网络吞吐量
2.2.4.1 定义及解释
网络吞吐量是指在无网络故障的情况下单位时间内通过的网络的数据数量。单位为Byte/s。
网络吞吐量指标用于衡量系统对于网络设备或链路传输能力的需求。当网络吞吐量指标接近网络设备或链路最大传输能力时，则需要考虑升级网络设备。
2.2.4.2 简称
Network Throughput
2.2.4.3 标准
网络吞吐量指标主要有每秒有多少兆流量进出，一般情况下不能超过设备或链路最大传输能力的70%。
2.2.5 内核参数
操作系统内核参数主要包括信号量、进程、文件句柄，一般不要超过设置的参数值即可，具体如下:
2.3 中间件指标
2.3.1 定义及解释
常用的中间件例如Tomcat、Weblogic等指标主要包括JVM, ThreadPool, JDBC,具体如下：
2.3.2 标准
?当前正在运行的线程数不能超过设定的最大值。一般情况下系统性能较好的情况下，线程数最小值设置50和最大值设置200比较合适。
?当前运行的JDBC连接数不能超过设定的最大值。一般情况下系统性能较好的情况下，JDBC最小值设置50和最大值设置200比较合适。
?ＧＣ频率不能频繁，特别是FULL GC更不能频繁，一般情况下系统性能较好的情况下，JVM最小堆大小和最大堆大小分别设置1024M比较合适。
2.4 数据库指标
2.4.1 定义及解释
常用的数据库例如ＭySQL指标主要包括SQL、吞吐量、缓存命中率、连接数等，具体如下：
2.4.2 标准
?SQL耗时越小越好，一般情况下微秒级别。
?命中率越高越好，一般情况下不能低于95%。
?锁等待次数越低越好，等待时间越短越好。
2.5 前端指标
2.5.1 定义及解释
前端指标主要包括页面展示和网络所花的时间，具体如下：
2.5.2 标准
?页面要尽可能小及压缩。
?页面展示和花费时间越短越好。
2.6 稳定性指标
2.6.1 定义及解释
最短稳定时间：系统按照最大容量的80%或标准压力（系统的预期日常压力）情况下运行，能够稳定运行的最短时间。
一般来说，对于正常工作日（8小时）运行的系统，至少应该能保证系统稳定运行８小时以上。对于7*24运行的系统，至少应该能够保证系统稳定运行24小时以上。
如果系统不能稳定的运行，上线后，随着业务量的增长和长时间运行，将会出现性能下降甚至崩溃的风险。
2.6.2 标准
?TPS曲线稳定，没有大幅度的波动。
?各项资源指标没有泄露或异常情况。
2.7 批量处理指标
2.7.1 定义及解释
指批量处理程序单位时间内处理的数据数量。一般用每秒处理的数据量来衡量。处理效率是估算批量处理时间窗口最重要的计算指标。
关于批量处理时间窗口，不同系统的批量处理时间窗口在起止时间上可以部分重叠。另外，同一系统内部，也可能存在多个批量处理过程同时进行，其
时间窗口相互叠加。
长时间批量处理将会对联机在线实时交易产生重大的性能影响。
2.7.2 标准
?在数据量很大的情况下，批处理时间窗口时间越短越好。
?不能影响实时交易系统性能。
2.8 可扩展性指标
2.8.1 定义及解释
指应用软件或操作系统以群集方式部署，增加的硬件资源与增加的处理能力之间的关系。计算公式为：（增加性能/原始性能）/（增加资源/原始资源）*100%。
扩展能力应通过多轮测试获得扩展指标的变化趋势。
一般扩展能力你常好的应用系统，扩展指标应是线性或接近线性的，现在很多大规模的分布式系统的扩展能力非常好。
2.8.2 标准
?理想的扩展能力是资源增加几倍，性能就提升几倍。
?扩展能力至少在70%以上。
2.9 可靠性指标
2.9.1 双机热备
对于将双机热备作为可靠性保障手段的系统，可衡量的指标如下：
?节点切换是否成功及其消耗时间
?双机切换是否有业务中断
?节点回切是否成功及其耗时
?双机回切是否有业务中断
?节点回切过程中的数据丢失量
在进行双机切换的同时，使用压力发生工具模拟实际业务发生情况，对应用保持一定的性能压力，保证测试结果符合生产实际情况。
2.9.2 集群
对于使用集群方式的系统，主要通过以下方式考量其集群可靠性：
?集群中某个节点出现故障时，系统是否有业务中断情况出现
?在集群中新增一个节点时，是否需要重启系统
?当故障节点恢复后，加入集群，是否需要重启系统
?当故障节点恢复后，加入集群，系统是否有业务中断情况出现
?节点切换需要多长时间
在验证集群可靠性的同时，需根据具体情况使用压力工具模拟实际业务发生相关情况，对应用保持一定的性能压力，确保测试结果符合生产实际情况。
性能测试指标介绍 第一页 | 第二页 TPC-C 作为一家非盈利性机构，事务处理性能委员会（TPC）负责定义诸如TPC-C、TPC-H和TPC-W基准测试之类的事务处理与数据库性能基准测试，并依据这些基准测试项目发布客观性能数据。TPC基准测试采用极为严格的运行环境，并且必须在独立审计机构监督下进行。委员会成员包括大多数主要数据库产品厂商以及服务器硬件系统供应商。 相关企业参与TPC基准测试以期在规定运行环境中获得客观性能验证，并通过应用测试过程中所使用的技术开发出更加强健且更具伸缩性的软件产品及硬件设备。 TPC-C是一种旨在衡量联机事务处理（OLTP）系统性能与可伸缩性的行业标准基准测试项目。这种基准测试项目将对包括查询、更新及队列式小批量事务在内的广泛数据库功能进行测试。许多IT专业人员将TPC-C视为衡量“真实”OLTP系统性能的有效指示器。 TPC-C基准测试针对一种模拟订单录入与销售环境测量每分钟商业事务（tpmC）吞吐量。特别值得一提的是，它将专门测量系统在同时执行其它四种事务类型（如支付、订单状态更新、交付及证券级变更）时每分钟所生成的新增订单事务数量。独立审计机构将负责对基准测试结果进行公证，同时，TPC将出据一份全面彻底的测试报告。这份测试报告可以从TPC Web站点(https://www.doczj.com/doc/4511580974.html,)上获得。 tpmC定义: TPC-C的吞吐量，按有效TPC-C配置期间每分钟处理的平均交易次数测量，至少要运行12分钟。 1．TPC-C规范概要 TPC-C是专门针对联机交易处理系统（OLTP系统）的，一般情况下我们也把这类系统称为业务处理系统。TPC-C测试规范中模拟了一个比较复杂并具有代表意义的OLTP应用环境:假设有一个大型商品批发商，它拥有若干个分布在不同区域的商品库；每个仓库负责为10个销售点供货；每个销售点为3000个客户提供服务；每个客户平均一个订单有10项产品;所有订单中约1%的产品在其直接所属的仓库中没有存货，需要由其他区域的仓库来供货。 该系统需要处理的交易为以下几种： ?New-Order：客户输入一笔新的订货交易； ?Payment:更新客户账户余额以反映其支付状况; ?Delivery:发货(模拟批处理交易); ?Order-Status:查询客户最近交易的状态； ?Stock-Level:查询仓库库存状况，以便能够及时补货。 对于前四种类型的交易，要求响应时间在5秒以内；对于库存状况查询交易，要求响应时间在20秒以内。逻辑结构图：
Web性能测试的部分概况一般来说，一个Web请求的处理包括以下步骤： （1）客户发送请求 （2）web server 接受到请求，进行处理； （3）web server 向DB获取数据； （4）web server生成用户的object(页面)，返回给用户。给客户发送请求开始到最后一个字节的时间称为响应时间（第三步不包括在每次请求处理中）。 1.事务（Transaction） 在web性能测试中，一个事务表示一个“从用户发送请求->web server接受到请求，进行处理-> web server向DB获取数据->生成用户的object(页面)，返回给用户”的过程，一般的响应时间都是针对事务而言的。 2.请求响应时间 请求响应时间指的是从客户端发起的一个请求开始，到客户端接收到从服务器端返回的响应结束，这个过程所耗费的时间，在某些工具中，响应通常会称为“TTLB”，即"time to last byte"，意思是从发起一个请求开始，到客户端接收到最后一个字节的响应所耗费的时间，响应时间的单位一般为“秒”或者“毫秒”。一个公式可以表示：响应时间＝网络响应时间+应用程序响应时间。标准可参考国外的3/5/10原则： （1）在3秒钟之内，页面给予用户响应并有所显示，可认为是“很不错的”； （2）在3~5秒钟内，页面给予用户响应并有所显示，可认为是“好的”；
（3）在5~10秒钟内，页面给予用户响应并有所显示，可认为是“勉强接受的”； （4）超过10秒就让人有点不耐烦了，用户很可能不会继续等待下去； 3、事务响应时间 事务可能由一系列请求组成,事务的响应时间主要是针对用户而言,属于宏观上的概念，是为了向用户说明业务响应时间而提出的.例如:跨行取款事务的响应时间就是由一系列的请求组成的.事务响应时间是直接衡量系统性能的参数. 4.并发用户数 并发一般分为2种情况。一种是严格意义上的并发，即所有的用户在同一时刻做同一 件事情或者操作，这种操作一般指做同一类型的业务。比如在信用卡审批业务中，一 定数目的拥护在同一时刻对已经完成的审批业务进行提交；还有一种特例，即所有用 户进行完全一样的操作，例如在信用卡审批业务中，所有的用户可以一起申请业务，或者修改同一条记录。 另外一种并发是广义范围的并发。这种并发与前一种并发的区别是，尽管多个用 户对系统发出了请求或者进行了操作，但是这些请求或者操作可以是相同的，也可以 是不同的。对整个系统而言，仍然是有很多用户同时对系统进行操作，因此也属于并 发的范畴。 可以看出，后一种并发是包含前一种并发的。而且后一种并发更接近用户的实际 使用情况，因此对于大多数的系统，只有数量很少的用户进行“严格意义上的并发”。对于WEB性能测试而言，这2种并发情况一般都需要进行测试，通常做法是先进行严格意义上的并发测试。严格意义上的用户并发一般发生在使用比较频繁的模块中，尽 管发生的概率不是很大，但是一旦发生性能问题，后果很可能是致命的。严格意义上 的并发测试往往和功能测试关联起来，因为并发功能遇到异常通常都是程序问题，这 种测试也是健壮性和稳定性测试的一部分。
一、软件性能测试需要监控哪些关键指标？ 软件性能测试的目的主要有以下三点： ·评价系统当前性能，判断系统是否满足预期的性能需求。 ·寻找软件系统可能存在的性能问题，定位性能瓶颈并解决问题。 ·判定软件系统的性能表现，预见系统负载压力承受力，在应用部署之前，评估系统性能。 而对于用户来说，则最关注的是当前系统： ·是否满足上线性能要求？ ·系统极限承载如何？ ·系统稳定性如何？ 因此，针对以上性能测试的目的以及用户的关注点，要达到以上目的并回答用户的关注点，就必须首先执行性能测试并明确需要收集、监控哪些关键指标，通常情况下，性能测试监控指标主要分为：资源指标和系统指标，如下图所示，资源指标与硬件资源消耗直接相关，而系统指标则与用户场景及需求直接相关。 性能测试监控关键指标说明： ·资源指标 CPU使用率：指用户进程与系统进程消耗的CPU时间百分比，长时间情况下，一般可接受上限不超过85%。 内存利用率：内存利用率=（1-空闲内存/总内存大小）*100%，一般至少有10%可用内存，内存使用率可接受上限为85%。 磁盘I/O: 磁盘主要用于存取数据，因此当说到IO操作的时候，就会存在两种相对应的操作，存数据的时候对应的是写IO操作，取数据的时候对应的是是读IO操作，一般使用% Disk Time（磁盘用于读写操作所占用的时间百分比）度量磁盘读写性能。 网络带宽：一般使用计数器Bytes Total/sec来度量，Bytes Total/sec表示为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较。 ·系统指标： 并发用户数：某一物理时刻同时向系统提交请求的用户数。 在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求。 平均响应时间：系统处理事务的响应时间的平均值。事务的响应时间是从客户端提交访问请求到客户端接收到服务器响应所消耗的时间。对于系统快速响应类页面，一般响应时间为3秒左右。 事务成功率：性能测试中，定义事务用于度量一个或者多个业务流程的性能指标，如用户登录、保存订单、提交订单操作均可定义为事务，如下图所示：
?每台服务器每秒平均PV量= （（80%*总PV）/（24*60*60*（9/24）））/服务器数量， ?即每台服务器每秒平均PV量=2.14*（总PV）/* （24*60*60） /服务器数量 ?最高峰的pv量是1.29倍的平均pv值 性能测试策略 1.模拟生产线真实的硬件环境。 2.服务器置于同一机房，最大限度避免网络问题。 3.以PV为切入点，通过模型将其转换成性能测试可量化的TPS。 4.性能测试数据分为基础数据和业务数据两部分，索引和SQL都会被测试到。 5.日志等级设置成warn，避免大量打印log对性能测试结果的影响。 6.屏蔽ESI缓存，模拟最坏的情况。 7.先单场景，后混合场景，确保每个性能瓶颈都得到调优。 8.拆分问题，隔离分析，定位性能瓶颈。 9.根据性能测试通过标准，来判断被测性能点通过与否。 10.针对当前无法解决的性能瓶颈，录入QC域进行跟踪，并请专家进行风险评估。 性能测试压力变化模型
a点：性能期望值 b点：高于期望，系统资源处于临界点 c点：高于期望，拐点 d点：超过负载，系统崩溃 性能测试 a点到b点之间的系统性能，以性能预期目标为前提，对系统不断施加压力，验证系统在资源可接受范围内，是否能达到性能预期。 负载测试 b点的系统性能，对系统不断地增加压力或增加一定压力下的持续时间，直到系统的某项或多项性能指标达到极限，例如某种资源已经达到饱和状态等。 压力测试 b点到d点之间，超过安全负载的情况下，对系统不断施加压力，是通过确定一个系统的瓶颈或不能接收用户请求的性能点，来获得系统能提供的最大服务级别的测试。
稳定性测试 a点到b点之间，被测试系统在特定硬件、软件、网络环境条件下，给系统加载一定业务压力，使系统运行一段较长时间，以此检测系统是否稳定，一般稳定性测试时间为n*12小时。 监控指标 性能测试通常需要监控的指标包括： 1.服务器 Linux（包括CPU、Memory、Load、I/O）。 2.数据库：1.Mysql 2.Oracle（缓存命中、索引、单条SQL性能、数据库线程数、数据池连接数）。 3.中间件：1.Jboss 2. Apache（包括线程数、连接数、日志）。 4.网络：吞吐量、吞吐率。 5.应用： jvm内存、日志、Full GC频率。 6.监控工具（LoadRunner）：用户执行情况、场景状态、事务响应时间、TPS等。 7.测试机资源：CPU、Memory、网络、磁盘空间。 监控工具 性能测试通常采用下列工具进行监控： 1.Profiler。一个记录log的类，阿里巴巴集团自主开发，嵌入到应用代码中使用。 2.Jstat。监控java 进程GC情况，判断GC是否正常。 3.JConsole。监控java内存、java CPU使用率、线程执行情况等，需要在JVM参数中进行配置。 4.JMap。监控java程序是否有内存泄漏，需要配合eclipse插件或者MemoryAnalyzer 来使用。 5.JProfiler。全面监控每个节点的CPU使用率、内存使用率、响应时间累计值、线程执行情况等，需要在JVM参数中进行配置。 6.Nmon。全面监控linux系统资源使用情况，包括CPU、内存、I/O等，可独立于应用监控。
Wｅb性能测试得部分概况一般来说,一个Web请求得处理包括以下步骤: (1)客户发送请求 (2)ｗeb server接受到请求,进行处理; (3)wｅb ｓeｒver向DB获取数据; (4)web ｓerver生成用户得object(页面),返回给用户。给客户发送请求开始到最后一个字节得时间称为响应时间(第三步不包括在每次请求处理中)。 １。事务(Tｒanｓaｃtｉon) 在web性能测试中,一个事务表示一个“从用户发送请求->wｅｂ servｅr接受到请求,进行处理-＞ webｓeｒvｅr向DB获取数据—>生成用户得oｂject(页面),返回给用户”得过程,一般得响应时间都就是针对事务而言得。 2。请求响应时间 请求响应时间指得就是从客户端发起得一个请求开始,到客户端接收到从服务器端返回得响应结束,这个过程所耗费得时间,在某些工具中,响应通常会称为“TTLB”,即＂tiｍe to last bytｅ＂,意思就是从发起一个请求开始,到客户端接收到最后一个字节得响应所耗费得时间,响应时间得单位一般为“秒”或者“毫秒"。一个公式可以表示:响应时间=网络响应时间＋应用程序响应时间。标准可参考国外得３／5/10原则: (1)在3秒钟之内,页面给予用户响应并有所显示,可认为就是“很不错得"; (2)在3～５秒钟内,页面给予用户响应并有所显示,可认为就是“好得”; (３)在５~10秒钟内,页面给予用户响应并有所显示,可认为就是“勉强接受得"; (4)超过10秒就让人有点不耐烦了,用户很可能不会继续等待下去; 3、事务响应时间 事务可能由一系列请求组成,事务得响应时间主要就是针对用户而言,属于宏观上得概念,就是为了向用户说明业务响应时间而提出得、例如:跨行取款事务得响应时间就就是由一系列得请求组成得。事务响应时间就是直接衡量系统性能得参数。 ４、并发用户数 并发一般分为２种情况。一种就是严格意义上得并发,即所有得用户在同一时刻做同一件事情或者操作,这种操作一般指做同一类型得业务、比如在信用卡审批业务中,一定数目得拥护在同一时刻对已经完成得审批业务进行提交;还有一种特例,即所有用户进行完
一、性能测试时需关注的指标 [size=4] Memory: 内存使用情况可能是系统性能中最重要的因素。如果系统“页交换”频繁，说明内存不足。“页交换”是使用称为“页面”的单位，将固定大小的代码和数据块从 RAM 移动到磁盘的过程，其目的是为了释放内存空间。尽管某些页交换使 Windows 2000 能够使用比实际更多的内存，也是可以接受的，但频繁的页交换将降低系统性能。减少页交换将显著提高系统响应速度。要监视内存不足的状况，请从以下的对象计数器开始： Available Mbytes:可用物理内存数. 如果Available Mbytes的值很小（4 MB 或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。page/sec: 表明由于硬件页面错误而从磁盘取出的页面数，或由于页面错误而写入磁盘以释放工作集空间的页面数。一般如果pages/sec持续高于几百，那么您应该进一步研究页交换活动。有可能需要增加内存，以减少换页的需求（你可以把这个数字乘以4k就得到由此引起的硬盘数据流量）。Pages/sec 的值很大不一定表明内存有问题，而可能是运行使用内存映射文件的程序所致。 page read/sec:页的硬故障，page/sec的子集，为了解析对内存的引用，必须读取页文件的次数。阈值为>5. 越低越好。大数值表示磁盘读而不是缓存读。由于过多的页交换要使用大量的硬盘空间，因此有可能将导致将页交换内存不足与导致页交换的磁盘瓶径混淆。因此，在研究内存不足不太明显的页交换的原因时，您必须跟踪如下的磁盘使用情况计数器和内存计数器： Physical Disk\ % Disk Time Physical Disk\ Avg.Disk Queue Length 例如，包括 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。如果页面读取操作速率很低，同时 % Disk Time 和 Avg.Disk Queue Length的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。 要确定过多的页交换对磁盘活动的影响，请将 Physical Disk\ Avg.Disk sec/Transfer 和 Memory\ Pages/sec 计数器的值增大数倍。如果这些计数器的计数结果超过了 0.1，那么页交换将花费百分之十以上的磁盘访问时间。如果长时间发生这种情况，那么您可能需要更多的内存。Page Faults/sec:每秒软性页面失效的数目（包括有些可以直接在内存中满足而有些需要从硬盘读取）较page/sec只表明数据不能在内存的指定工作集中立即使用。 Cache Bytes：文件系统缓存（File System Cache），默认情况下为50%的可用物理内存。如IIS5.0 运行内存不够时，它会自动整理缓存。需要关注该计数器的趋势变化 如果您怀疑有内存泄露，请监视 Memory\ Available Bytes 和 Memory\ Committed Bytes，以观察内存行为，并监视您认为可能在泄露内存的进程的 Process\Private Bytes、Process\Working Set 和Process\Handle Count。如果您怀疑是内核模式进程导致了泄露，则还应该监视 Memory\Pool Nonpaged Bytes、
网站的性能测试指标包括了Web应用服务器、数据库服务器及系统服务器等各种性能测试。每一项测试中都需要根据项目要求完成测试，本文重点讲述了网站性能测试指标，并加以案例分析。 通用指标（指Web应用服务器、数据库服务器必需测试项) Web服务器指标 数据库服务器性能指标 系统的瓶颈定义
稳定系统的资源状态 通俗理解： ·日访问量 ·常用页面最大并发数 ·同时在线人数 ·访问相应时间 案例： 最近公司一个项目，是个门户网站，需要做性能测试，根据项目特点定出了主要测试项和测试方案： 一种是测试几个常用页面能接受的最大并发数(用户名参数化，设置集合点策略) 一种是测试服务器长时间压力下，用户能否正常操作(用户名参数化，迭代运行脚本) 一种则需要测试服务器能否接受10万用户同时在线操作，如果是用IIS做应用服务器的话，单台可承受的最大并发数不可能达到10万级，那就必须要使用集群，
通过多台机器做负载均衡来实现；如果是用websphere之类的应用服务器的话，单 台可承受的最大并发数可以达到10万级，但为性能考虑还是必须要使用集群，通 过多台机器做负载均衡来实现；通常有1个简单的计算方式，1个连接产生1个session，每个session在服务器上有个内存空间大小的设置，在NT上是3M，那么10万并发就需要300G内存，当然实际使用中考虑其他程序也占用内存，所以准备 的内存数量要求比这个还要多一些。还有10万个用户同时在线，跟10万个并发数是完全不同的2个概念。这个楼上已经说了。但如何做这个转换将10万个同时在 线用户转换成多少个并发数呢？这就必须要有大量的历史日志信息来支撑了。系统日志需要有同时在线用户数量的日志信息，还需要有用户操作次数的日志信息，这 2个数据的比例就是你同时在线用户转换到并发数的比例。另外根据经验统计，对 于1个JAVA开发的WEB系统（别的我没统计过，给不出数据），一般1台双CPU、2G内存的服务器上可支持的最大并发数不超过500个（这个状态下大部分 操作都是超时报错而且服务器很容易宕机，其实没什么实际意义），可正常使用（单步非大数据量操作等待时间不超过20秒）的最大并发数不超过300个。假设 你的10万同时在线用户转换的并发数是9000个，那么你最少需要这样的机器18台，建议不少于30台。当然，你要是买个大型服务器，里面装有200个CPU、 256G的内存，千兆光纤带宽，就算是10万个并发用户，那速度，也绝对是嗖嗖的。 另外暴寒1下，光设置全部进入运行状态就需要接近6个小时。具体的可以拿1个 系统来压一下看看，可能会出现以下情况： 1、服务器宕机； 2、客户端宕机； 3、从某个时间开始服务器拒绝请求，客户端上显示的全是错误； 4、勉强测试完成，但网络堵塞或测试结果显示时间非常长。假设客户端和服务器 之间百兆带宽，百兆/10000=10K，那每个用户只能得到10K，这个速度接近1个 64K的MODEM上网的速度；另外以上分析全都没考虑系统的后台，比如数据库、中间件等。 1、服务器方面：上面说的那样的PC SERVER需要50台； 2、网络方面：按每个用户50K，那至少5根百兆带宽独享，估计仅仅网络延迟就 大概是秒一级的； 3、如果有数据库，至少是ORACLE，最好是SYSBASE，SQL SERVER是肯定顶 不住的。数据库服务器至少需要10台4CPU、16G内存的机器； 4、如果有CORBA，那至少再准备10台4CPU、16G内存的机器；再加上负载均衡、防火墙、路由器和各种软件等，总之没个1000万的资金投入，肯定搞不定。
通用指标（指Web应用服务器、数据库服务器必需测试项) Web服务器指标
数据库服务器性能指标 系统的瓶颈定义
稳定系统的资源状态 通俗理解： 日访问量 常用页面最大并发数
同时在线人数 访问相应时间 案例： 最近公司一个项目，是个门户网站，需要做性能测试，根据项目特点定出了主要测试项和测试方案： 一种是测试几个常用页面能接受的最大并发数(用户名参数化，设置集合点策略) 一种是测试服务器长时间压力下，用户能否正常操作(用户名参数化，迭代运行脚本) 一种则需要测试服务器能否接受10万用户同时在线操作，如果是用IIS做应用服务器的话，单台可承受的最大并发数不可能达到10万级，那就必须要使用集群，通过多台机器做负载均衡来实现；如果是用websphere之类的应用服务器的话，单台可承受的最大并发数可以达到10万级，但为性能考虑还是必须要使用集群，通过多台机器做负载均衡来实现；通常有1个简单的计算方式，1个连接产生1个session，每个session在服务器上有个内存空间大小的设置，在NT上是3M，那么10万并发就需要300G内存，当然实际使用中考虑其他程序也占用内存，所以准备的内存数量要求比这个还要多一些。还有10万个用户同时在线，跟10万个并发数是完全不同的2
个概念。这个楼上已经说了。但如何做这个转换将10万个同时在线用户转换成多少个并发数呢？这就必须要有大量的历史日志信息来 支撑了。系统日志需要有同时在线用户数量的日志信息，还需要有用户操作次数的日志信息，这2个数据的比例就是你同时在线用户转换到并发数的比例。另外根据经验统计，对于1个JAVA开发的WEB 系统（别的我没统计过，给不出数据），一般1台双CPU、2G内存的服务器上可支持的最大并发数不超过500个（这个状态下大部分操作都是超时报错而且服务器很容易宕机，其实没什么实际意义），可正常使用（单步非大数据量操作等待时间不超过20秒）的最大并发数不超过300个。假设你的10万同时在线用户转换的并发数是9000个，那么你最少需要这样的机器18台，建议不少于30台。当然，你要是买个大型服务器，里面装有200个CPU、256G的内存，千兆光纤带宽，就算是10万个并发用户，那速度，也绝对是嗖嗖的。 另外暴寒1下，光设置全部进入运行状态就需要接近6个小时。具体的可以拿1个系统来压一下看看，可能会出现以下情况： 1、服务器宕机； 2、客户端宕机； 3、从某个时间开始服务器拒绝请求，客户端上显示的全是错误； 4、勉强测试完成，但网络堵塞或测试结果显示时间非常长。假设客户端和服务器之间百兆带宽，百兆/10000=10K，那每个用户只
Weｂ性能测试的部分概况一般来说,一个Ｗeb请求的处理包括以下步骤: (1)客户发送请求 (2)weｂservｅr 接受到请求,进行处理; (3)weｂ servｅｒ向ＤB获取数据; (４)web serｖｅr生成用户的obｊeｃt(页面),返回给用户。给客户发送请求开始到最后一个字节的时间称为响应时间(第三步不包括在每次请求处理中)。 1.事务(Tranｓacｔion) 在ｗeb性能测试中,一个事务表示一个“从用户发送请求->web sｅrveｒ接受到请求,进行处理-＞ｗeｂ serveｒ向DＢ获取数据->生成用户的object(页面),返回给用户”的过程,一般的响应时间都就是针对事务而言的。 2、请求响应时间 请求响应时间指的就是从客户端发起的一个请求开始,到客户端接收到从服务器端返回的响应结束,这个过程所耗费的时间,在某些工具中,响应通常会称为“TTLB”,即＂tｉme ｔｏ lａst ｂｙｔe",意思就是从发起一个请求开始,到客户端接收到最后一个字节的响应所耗费的时间,响应时间的单位一般为“秒”或者“毫秒”。一个公式可以表示:响应时间＝网络响应时间+应用程序响应时间。标准可参考国外的3/５/1０原则: (1)在3秒钟之内,页面给予用户响应并有所显示,可认为就是“很不错的”; (2)在３~５秒钟内,页面给予用户响应并有所显示,可认为就是“好的”;
(３)在5～10秒钟内,页面给予用户响应并有所显示,可认为就是“勉强接受的”; (４)超过１0秒就让人有点不耐烦了,用户很可能不会继续等待下去; 3、事务响应时间 事务可能由一系列请求组成,事务的响应时间主要就是针对用户而言,属于宏观上的概念,就是为了向用户说明业务响应时间而提出的、例如:跨行取款事务的响应时间就就是由一系列的请求组成的、事务响应时间就是直接衡量系统性能的参数、 ４.并发用户数 并发一般分为2种情况。一种就是严格意义上的并发,即所有的用户在同一时刻做同一件事情或者操作,这种操作一般指做同一类型的业务。比如在信用卡审批业务中,一定数目的拥护在同一时刻对已经完成的审批业务进行提交;还有一种特例,即所有用户进行完全一样的操作,例如在信用卡审批业务中,所有的用户可以一起申请业务,或者修改同一条记录。 另外一种并发就是广义范围的并发。这种并发与前一种并发的区别就是,尽管多个用户对系统发出了请求或者进行了操作,但就是这些请求或者操作可以就是相同的,也可以就是不同的。对整个系统而言,仍然就是有很多用户同时对系统进行操作,因此也属于并发的范畴。 可以瞧出,后一种并发就是包含前一种并发的。而且后一种并发更接近用户的实际使用情况,因此对于大多数的系统,只有数量很少的用户进行“严格意义上的并发”。对于ＷEB性能测试而言,这2种并发情况一般都需要进行测试,通常做法就是先进行严格意义上的并发测试。严格意义上的用户并发一般发生在使用比较频繁的模块中,尽管发生的概率不就是很大,但就是一旦发生性能问题,后果很可能就是致命的。严格意义上的并发测试往往与功能测试关联起来,因为并发功能遇到异常通常都就是程序问题,这种测试也就是健壮性与稳定性测试的一部分。
XXX项目 性能测试方案
修订记录
目录 1项目简介 (1) 1.1测试目标 (1) 1.2测试范围 (1) 1.3性能测试指标要求 (2) 1.3.1 交易吞吐量 (2) 1.3.2 交易响应时间 (2) 1.3.3并发交易成功率 (2) 1.3.4资源使用指标 (2) 2测试环境 (3) 2.1网络拓扑图 (3) 2.2软硬件配置 (3) 3测试方案 (5) 3.1交易选择 (5) 3.2测试数据 (5) 3.2.1 参数数据 (5) 3.2.2 存量数据 (6) 3.3资源监控指标 (6) 3.3.1台式机 (6) 3.3.2服务器 (6) 3.4测试脚本编写与调试 (6) 3.5测试场景设计 (6) 3.5.1典型交易基准测试 (6) 3.5.2典型交易常规并发测试 (7) 3.5.3稳定性测试 (8) 3.6测试场景执行与数据收集 (9) 3.7性能优化与回归 (9) 4测试实施情况 (10) 4.1测试时间和地点 (10) 4.2参加测试人员 (10) 4.3测试工具 (10) 4.4性能测试计划进度安排 (11) 5专业术语 (12)
1 项目简介 1.1测试目标 通过对XXXXXX系统的性能测试实施，在测试范围内可以达到如下目的： 了解XXX系统在各种业务场景下的性能表现； 了解XXX业务系统的稳定性； 通过各种业务场景的测试实施，为系统调优提供数据参考； 通过性能测试发现系统瓶颈，并进行优化。 预估系统的业务容量 1.2测试范围 XXX系统说明以及系统业务介绍和需要测试的业务模块，业务逻辑图如下：
本公司服务器环境以及架构图 为了真实反映XXXX系统自身的处理能力，本次测试范围只包（XXX服务器系统和Web服务系统、数据库服务器系统）。 1.3性能测试指标要求 本次性能测试需要测试的性能指标包括： 1、交易吞吐量：后台主机每秒能够处理的交易笔数（TPS） 2、交易响应时间（3-5-8秒） 3、并发交易成功率99.999% 4、资源使用指标：前置和核心系统各服务器CPU（80%）、内存占用率（80%）、Spotlighton 数据库；LoadRunner压力负载机CPU占用率、内存占用率 1.3.1 交易吞吐量 根据统计数据，XXX系统当前生产环境高峰日交易总量为【】万笔。根据二八原则（80%的交易量发生在20%的时间段内），当前生产环境对主机的交易吞吐量指标要求为：TPS_1 ≥【】 * 80% / (24 * 20% * 3600) = 【】笔/秒 为获取系统主机的最大处理能力，在本次性能测试中可通过不断加压，让数据系统主机CPU利用率达到【】%，记录此时的TPS值，作为新主机处理能力的一个参考值。 1.3.2 交易响应时间 本次性能测试中的交易响应时间是指由性能测试工具记录和进行统计分析的、系统处理交易的响应时间，用一定时间段内的统计平均值ART来表示。 本次性能测试中，对所有交易的ART指标要求为： ART ≤ 5 秒 1.3.3并发交易成功率 指测试结束时成功交易数占总交易数的比率。交易成功率越高，系统越稳定。 对典型交易的场景测试，要求其并发交易成功率≥ 99.999% 。 1.3.4资源使用指标 在正常的并发测试和批处理测试中，核心系统服务器主机的资源使用指标要求：CPU使用率≤ 80% 内存使用率≤ 80%
服务器性能测试指标介绍 当前业界常见的服务器性能指标有: TPC-C TPC-E TPC-H SPECjbb2005 SPECjEnterprise2010 SPECint2006 及SPECint_rate_2006 SPECfp2006 及SPECfp_rate_2006 SAP SD 2-Tier LINPACK RPE2 一、TPC (Transaction Processing Performance Council) 即联机交易处理性能协会, 成立于1988年的非盈利组织,各主要软硬件供应商均参与,成立目标: 为业界提供可信的数据库及交易处理基准测试结果,当前发布主要基准测试为: TPC-C : 数据库在线查询(OLTP)交易性能 TPC-E : 数据库在线查询(OLTP)交易性能 TPC-H : 商业智能/ 数据仓库/ 在线分析(OLAP)交易性能 1.TPC-C测试内容：数据库事务处理测试, 模拟一个批发商的订单管理系统。实际衡量服务器及数据库软件处理在线查询交易处理（OLTP）的性能表现. 正规TPC-C 测试结果发
布必须提供tpmC值, 即每分钟完成多少笔TPC-C 数据库交易(TPC-C Transaction Per Minute), 同时要提供性价比$/tpmC。如果把TPC-C 测试结果写成为tpm, TPM, TPMC, TPCC 均不属正规。 2.TPC-E测试内容：数据库事务处理测试，模拟一个证券交易系统。与TPC-C一样，实际衡量服务器及数据库软件处理在线查询交易处理（OLTP）的性能表现。正规TPC-E测试结果必须提供tpsE值，即每秒钟完成多少笔TPC-E数据库交易（transaction per second），同时提供$/tpsE。测试结果写成其他形式均不属正规。 对比：TPC-E测试较TPC-C测试，在测试模型搭建上增加了应用服务器层，同时增加了数据库结构的复杂性,测试成本相对降低。截止目前，TPC-E的测试结果仅公布有50种左右，且测试环境均为PC服务器和windows操作系统，并无power服务器的测试结果。除此之外，TPC官方组织并未声明TPC-E取代TPC-C，所以，说TPC-E取代TPC-C并没有根据。 附TPC-C与TPC-E数据库结构对比 3.TPC-H测试内容：对大型数据仓库进行决策支持（decision support)的基准测试。TPC-H包含一组复杂的业务查询及修改操作，属于商业智能/数据仓库/在线分析（OLAP）
web性能测试基本性能指标 Web性能测试的部分概况一般来说，一个Web请求的处理包括以下步骤： （1）客户发送请求 （2）web server接受到请求，进行处理； （3）web server向DB获取数据； （4）web server生成用户的object(页面)，返回给用户。给客户发送请求开始到最后一个字节的时间称为响应时间（第三步不包括在每次请求处理中）。 1.事务（Transaction） 在web性能测试中，一个事务表示一个“从用户发送请求->web server接受到请求，进行处理->we b server向DB获取数据->生成用户的object(页面)，返回给用户”的过程，一般的响应时间都是针对事务而言的。 2.请求响应时间 请求响应时间指的是从客户端发起的一个请求开始，到客户端接收到从服务器端返回的响应结束，这个过程所耗费的时间，在某些工具中，响应通常会称为“TTLB”，即"time to last byte"，意思是从发起一个请求开始，到客户端接收到最后一个字节的响应所耗费的时间，响应时间的单位一般为“秒”或者“毫秒”。一个公式可以表示：响应时间＝网络响应时间+应用程序响应时间。标准可参考国外的3/5/10原则： （1）在3秒钟之内，页面给予用户响应并有所显示，可认为是“很不错的”； （2）在3~5秒钟内，页面给予用户响应并有所显示，可认为是“好的”； （3）在5~10秒钟内，页面给予用户响应并有所显示，可认为是“勉强接受的”； （4）超过10秒就让人有点不耐烦了，用户很可能不会继续等待下去； 3、事务响应时间 事务可能由一系列请求组成,事务的响应时间主要是针对用户而言,属于宏观上的概念，是为了向用户说明业务响应时间而提出的.例如:跨行取款事务的响应时间就是由一系列的请求组成的.事务响应时间是直接衡量系统性能的参数. 4.并发用户数 并发一般分为2种情况。一种是严格意义上的并发，即所有的用户在同一时刻做同一件事情或者操作，这种操作一般指做同一类型的业务。比如在信用卡审批业务中，一定数目的拥护在同一时刻对已经完成的审批业务进行提交；还有一种特例，即所有用户进行完全一样的操作，例如在信用卡审批业务中，所有的用户可以一起申请业务，或者修改同一条记录。 另外一种并发是广义范围的并发。这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或者操作可以是相同的，也可以是不同的。对整个系统而言，仍然是有很多用户同时对系统进行操作，因此也属于并发的范畴。
web项目性能测试方案 任务： 测试JBOSS环境下UBSS项目的性能 目标：测试缴费部分（前台缴费，IC卡充值）在并发数从50-100递增的性能指标，不要求对结果进行分析 步骤： 1.搭建测试环境，要求与真实环境大概一致（关注在现有license情况下，UBSS系统支持的最大并发数） 2.准备数据脚本（SQL和存储过程） 3.准备测试脚本（Vuser scrīpts,scenario） 4.进行性能测试 测试范围 针对UBSS项目，抽取对系统影响最大、最为典型的业务交易，构建场景，以此评判系统的整体性能和实际性能表现 a.用户前台缴费 b.标准用户IC卡充值 测试内容 1.基准测试 概念：检查每个业务的基准响应时间（系统整体空闲，无额外进程运行并占用系统资源）方法：单用户运行业务多次，获取该业务的平均响应时间 序号功能名称并发用户数循环次数操作间隔循环间隔 1-1 前台缴费 1 100 3 3 1-2 IC卡充值 1 100 3 3 2.单个交易负载测试 概念：设定负载序列，并发用户数为X｛20,30,50,....｝,收集系统单个交易在不同负载级别的性能表现 方法：设置并发用户数等于X，关键步骤处设置并发点，每个用户运行N个iteration，获取平均响应时间和吞吐量 用户登陆方式：每2秒登陆2个 序号功能名称并发用户数循环次数操作间隔循环间隔 2-1 前台缴费 5 50 3 3 2-2 前台缴费10 50 3 3 2-3 前台缴费15 50 3 3 注：响应时间超过30S 2-4 前台缴费20 50 3 3 注：阻塞，不进行测试 2-5 IC卡充值 5 50 3 3 2-6 IC卡充值10 50 3 3 2-7 IC卡充值15 50 3 3 2-8 IC卡充值20 50 3 3 3.组合交易负载测试 概念：多个交易组合在一起，设定负载序列，并发数为X｛20,30,50,....｝，收集系统在不同负载级别的性能表现 方法：设置并发总数，各用户数按比例分配，每个用户运行N分钟，获取平均响应时间和吞吐量 序号功能名称并发用户总数比例持续时间操作间隔循环间隔
XXX项目or府门户网站性能测试报告
目录 第一章概述 (4) 第二章测试活动 (4) 2.1 测试用具 (4) 2.2 测试范围 (4) 2.3 测试目标 (5) 2.4 测试方法 (5) 2.4.1 基准测试 (5) 2.4.2 并发测试 (6) 2.4.3 稳定性测试 (6) 2.5 性能指标 (6) 2.6 性能测试流程 (6) 2.7 测试术语 (7) 第三章性能测试环境 (8) 3.1 服务器环境 (8) 3.2 客户端环境 (8) 3.3 网络结构 (8) 第四章测试方案 (10) 4.1 基准测试 (11) 4.2 并发测试 (12) 4.3 稳定性测试 (13) 第五章测试结果描述和分析 (15) 6.1基准测试性能分析 (15) 6.2并发测试性能分析 (20) 6.3稳定性性能测试分析 (27) 第六章测试结论 (28)
摘要 本文档主要描述XXXX网站检索和页面浏览性能测试中的测试内容、测试方法、测试策略等。 修改历史
第一章概述 由于当前对系统要接受业务量的冲击，面临的系统稳定、成熟性方面的压力。系统的性 能问题必将成为焦点问题，海量数据量的“冲击”，系统能稳定在什么样的性能水平，面临业务增加时，系统抗压如何等这些问题需要通过一个较为真实的性能模拟测试来给出答案，通过测试和分析为系统性能的提升提供一些重要参考数据，以供后期系统在软硬件方面的改 善和完善。 本《性能测试报告》即是基于上述考虑，参考当前的一些性能测试方法而编写的，用以 指导即将进行的该系统性能测试。 第二章测试活动 2.1测试用具 本次性能测试主要采用 HP 公司的 Loadrunner11 作为性能测试工具。Load runner 主要提供了 3 个性能测试组件：Virtual User Generator, Controller,Analysis。 ●使用 Virtual User Generator 修改和优化脚本。 ●使用 Controller 进行管理，控制并发的模拟并发数，记录测试结果。 ●使用 Analysis 进行统计和分析结果。 2.2测试范围 此次性能测试实施是对吴忠市门户网站系统性能进行测试评估的过程，我们将依据系统 将来的实际运行现状，结合系统的设计目标和业务特点，遵循着发生频率高、对系统或数据 库性能影响大、关键和核心业务等原则选取需要进行测试的业务，模拟最终用户的操作行为， 构建一个与生产环境相近的压力场景，对系统实施压力测试，以此评判系统的实际性能表现。 根据与相关设计，开发人员的沟通和交流，本次测试主要就是针对大量用户在使用吴忠 市门户网站进行信息查询，而选取的典型事务就是用户使用检索进行关键字搜索以及界面浏 览和反馈回搜索结果，这是用户使用最频繁，反应最多的地方，也是本系统当前以及以后业 务的一个重要压力点所在。所以本次测试只选取检索业务的性能情况和界面浏览进行记录和
1 引言 1.1 编写目的 本文总结提炼性能测试相关项目实施经验，规范使用性能测试进行性能测试系统技术指标，规范技术测试结果评价，统一性能测试技术测试质量度量。应用系统技术质量度量指标范围广泛，本文难以涵盖全部。用常用指标来进行说明，其他未说明指标将在后续测试工作中继续补充和完善本指标体系。 1.2 适用对象和范围 本指标适用于使用性能测试进行性能测试项目技术质量评价依据。预期读者为测试管理人员、测试实施人员、技术支持人员、项目管理人员等系统技术质量相关人员。 2 系统性能指标
2.1 业务指标 业务指标主要包括并发用户数、响应时间、处理能力，这三个指标有一定的关系的，具体可参照：《并发用户数与TPS关系》 2.1.1 交易响应时间 2.1.1.1 定义及解释 响应时间指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的响应结束，整个过程所耗费的时间。在性能检测中一般以测试环境中压力发起端至服务器返回处理结果的时间为计量，单位一般为秒或毫秒,该时间不同于模拟真实环境的用户体验时间。 平均响应时间：指系统稳定运行时间段内，同一交易的平均响应时间。一般而言，交易响应时间均指平均响应时间。 平均响应时间指标值应根据不同的交易分别设定，一般情况下，分为复杂交易响应时间、简单交易响应时间、特殊交易响应时间。其中，特殊交易响应时间的设定必须明确该交易在响应时间方面的特殊性。 2.1.1.2 简称 Response Time: RT
2.1.1.3 标准 不同行业不同业务可接受的响应时间是不同的，一般情况，对于在线实时交易： ?互联网企业：500毫秒以下，例如淘宝业务10毫秒左右。 ?金融企业：1秒以下为佳，部分复杂业务3秒以下。 ?保险企业：3秒以下为佳。 ?制造业：5秒以下为佳。 对于批量交易： ?时间窗口：不同数据量结果是不一样的，大数据量的情况下，2小时内完成。 2.1.2 系统处理能力 2.1.2.1 定义及解释 系统处理能力是指系统在利用系统硬件平台和软件平台进行信息处理的能力。 系统处理能力通过系统每秒钟能够处理的交易数量来评价，交易有两种理解：一是业务人员角度的一笔业务过程；二是系统角度的一次交易申请和响应过程。前者称为业务交易过程，后者称为事务。两种交易指标都可以评价应用系统的处理能力。一般的建议与系统交易日志保持一致，以便于统计业务量或者交易量。系统处理能力指标是技术测试活动中重要指标。
性能测试方案
目录目录
前言 平台XX项目系统已经成功发布，依据项目的规划，未来势必会出现业务系统中信息大量增长的态势。 随着业务系统在生产状态下日趋稳定、成熟，系统的性能问题也逐步成为了我们关注的焦点：每天大数据量的“冲击”，系统能稳定在什么样的性能水平，面临行业公司业务增加时，系统能否经受住“考验”，这些问题需要通过一个完整的性能测试来给出答案。 本《性能测试计划书》即是基于上述考虑，参考科学的性能测试方法而撰写的，用以指导即将进行的系统的性能测试。 1第一章XXX系统性能测试概述 1.1被测系统定义 XXX系统作为本次测试的被测系统（注：以下所有针对被测系统地描述均为针对XXX系统进行的），XXX系统是由平台开发的一款物流应用软件，后台应用了Oracle11g数据库，该系统包括主要功能有:XXX等。在该系统中都存在多用户操作，大数据量操作以及日报、周报、年报的统计，在本次测试中，将针对这些多用户操作，大数据量的查询、统计功能进行如预期性能、用户并发、大数据量、疲劳强度和负载等方面的性能测试，检查并评估在模拟环境中，系统对负载的承受能力，在不同的用户连接情况下，系统的吞吐能力和响应能力，以及在预计的数据容量中，系统能够容忍的最大用户数。 1.1.1功能简介 主要功能上面已提到，由于本文档主要专注于性能在这里功能不再作为重点讲述。
1.1.2性能测试指标 本次测试是针对XXX系统进行的全面性能测试，主要需要获得如下的测试指标。 1、应用系统的负载能力：即系统所能容忍的最大用户数量，也就是在正常的响应时间中，系统能够支持的最多的客户端的数量。 2、应用系统的吞吐量：即在一次事务中网络内完成的数据量的总和，吞吐量指标反映的是服务器承受的压力。事务是用户某一步或几步操作的集合。 3、应用系统的吞吐率：即应用系统在单位时间内完成的数据量，也就是在单位时间内，应用系统针对不同的负载压力，所能完成的数据量。 4、TPS：每秒钟系统能够处理事务或交易的数量，它是衡量系统处理能力的重要指标。 5、点击率：每秒钟用户向服务器提交的HTTP请求数。 5、系统的响应能力：即在各种负载压力情况下，系统的响应时间，也就是从客户端请求发起，到服务器端应答返回所需要的时间，包括网络传输时间和服务器处理时间。 6、应用系统的可靠性：即在连续工作时间状态下，系统能够正常运行的时间，即在连续工作时间段内没有出错信息。 1.2系统结构及流程 XXX系统在实际生产中的体系结构跟本次性能测试所采用的体系结构是一样的，交易流程也完全一致的。不过，由于硬件条件的限制，本次性能测试的硬件平台跟实际生产环境略有不同。 1.2.1系统总体结构 描述本系统的总体结构，包括：硬件组织体系结构、网络组织体系结构、软件组织体系结构和功能模块的组织体系结构。