压力测试报告

压力测试报告1. 引言2

1.1 编写目的 2

1.2 系统概述 2

1.2.1 项目名称2

1.2.2 总体目标2

1.2.3 技术目标2

2. 测试环境2

2.1 软硬件环境2

2.1.1网络拓扑结构3

2.4 测试环境约束3

3. 测试范畴及测试要求3

3.1测试3

3.1.1测试内容3

3.1.2测试通过标准3

4. 测试工具3

5. 测试结果3

6.1测试时刻及人员3

6.2测试结果分析4

6. 结论10

引言

1.1 编写目的

本文档是对(项目名称)性能测试所做的讲明，为充分利用已有的软硬件资源，配合对各系统应用模块的运行测试方案,查缺补漏完善系统的各项具体功能,保证项目的顺利进行，本测试报告有助于实现以下目标：明确此次性能测试的测试资源；

明确此次性能测试的测试内容；

明确此次性能测试的测试方法；

明确此次性能测试的系统性能。

1.2 系统概述

1.2.1 项目名称

项目名称: 小象工程

项目简称: 小象工程

项目单位: 扑像文化传播有限公司

1.2.2 总体目标

1.2.3 技术目标

1.2.3.1技术目标

使用测试工具实现虚拟用户并发的压力测试，要求系统满足用户并发量在100以上，并能正常工作。

测试环境

硬件环境应用服务器数据库服务器客户端

硬件配置CPU 3.40GHz

Memory：2G

HD: 360G

SATA CPU 3.40GHz

Memory：2G

HD: 360G

SATA

CPU 2.20GHz

Memory：2G

HD: 360G

SATA

软件配置OS：Windows 2003

JDK 1.5.0_06

Tomcat 6OS：Windows 2003

MySQL 5.0.17 Linux

Window xp

Professional （SP3 ）

2.1.1网络拓扑结构

2.4 测试环境约束

此次测试结果依据目前被测系统的软/硬件环境。

此次测试结果依据目前被测系统的程序版本。

此次测试结果依据目前被测系统的网络环境。

此次测试结果依据目前被测系统的测试数据量。

测试范畴及测试要求

3.1测试

3.1.1测试内容

按照需求，对登录操作进行并发的压力测试，对要紧业务模块中的要紧业务（下点单、制作相册）进行压力和负载测试。

3.1.2测试通过标准

系统在并发用户100时，系统表现稳固

测试工具

测试工具：

Loadrunner8.0（美国Mercury公司）

使用Web（http/html）协议。

要紧思想是使用虚拟用户（Virtual users）来模拟实际用户对系统施加压力。

模拟图如下：

测试结果

6.1测试时刻及人员

时刻：2011.08.09

人员：玲

地点：深圳扑象文化传播有限公司

6.2测试结果分析

LoadRunner进行100用户场景模拟测试结果收集后，显示的该结果的一个摘要信息，如图5- 1所示。概要中列出了场景执行情形、“Statistics S ummary（统计信息摘要）”、“Transaction Summary（事务摘要）”以及“HT TP Responses Summary（HTTP响应摘要）”等。以简要的信息列出此次测试结果。

图5- 1性能测试结果摘要图

场景执行情形

该部分给出了此次测试场景的名称、结果存放路径及场景的连续时刻，如图5- 2所示。从该图我们明白，此次测试从16:17:08开始，到16:54:38终止，共历时37分30秒。

图5- 2场景执行情形描述图

Statistics Summary（统计信息摘要）

该部分给出了场景执行终止后并发数、总吞吐量、平均每秒吞吐量、总要求数、平均每秒要求数的统计值，如图5- 3所示。从该图我们得知，此次测试运行的最大并发数为200，总吞吐量为960,974,180字节，平均每秒的吞吐量为426910字节，总的要求数为117,105，平均每秒的要求为52. 024。

图5- 3统计信息摘要图

Transaction Summary（事务摘要）

该部分给出了场景执行终止后有关Action的平均响应时刻、通过率等情形，如图5- 4所示。从该图我们得到每个Action的平均响应时刻与业务成功率。

图5- 4事务摘要图

HTTP Responses Summary（HTTP响应摘要）

该部分显示在场景执行过程中，每次HTTP要求发出去的状态，是成功依旧失败，都在那个地点体现，如图5- 5所示。从图中能够看到，在此次测试过程中LoadRunner共模拟发出了117105次要求（与“统计信息摘要”中的“Total Hits”一致），其中“HTTP 200”的是117105次，讲明在此次过程中，通过发出的要求全部分都能正确响应了（“HTTP 200”表示要求被正确响应）。

图5- 5 HTTP响应摘要

并发数分析

“Running Vusers（运行的并发数）”显示了在场景执行过程中并发数的执行情形。它们显示Vuser的状态、完成脚本的Vuser的数量以及集合统计信息，将这些图与事务图结合使用能够确定Vuser的数量对事务响应时刻产生的阻碍。图5- 6显示了在系统业务性能测试过程中Vusers运行情形，从图中我们能够看到，Vusers的运行趋势与我们场景执行打算中的设置是一样，表明在场景执行过程中，Vusers是按照我们预期的设置运行的，没有Vuser显现运行错误，如此从另一个侧面讲明我们的参数化设置是正确的，因为使用唯独数进行参数化设置，如果设置不正确，将会导致Vuser 运行错误。

Color Scale Measurement Graph Min. Graph Ave. Graph Max. Graph Median Graph SD

1 Run 0.0 105.1 200 129 78.219

图5- 6运行的并发数图

我们此次测试Running Vusers与集合点是一致，讲明整个场景执行过程中，并发数用户的执行正确，系统测试服务器能够应对200个并发用户的业务操作。

响应时刻

“Average Transaction Response Time（平均事务响应时刻图）”（图5-7），这张图是平均事务响应时刻与结果摘要中的“Transaction Summary”合成的。

Color Scale Measurement Min. Ave. Max. SD

1 login_Action_Transaction 0.45

2 47.115 109.38 30.257

1 select_allAction_Transaction 8.719 26.648 144.704 11.231

1 select_oneAction_Transaction 24.484 93.983 329.974 39.933

1 vuser_end_Transaction 0.0 0.011 1.297 0.097

1 vuser_init_Transaction 0.001 0.05 0.418 0.095

图5- 7平均事务响应时刻图

从图形下部我们能够看到，登录部分对应的Action是“login_Action”，批量查询对应的Action是“select_allAction”，选择信息查询对应的Action 是“select_oneAction”，他们的“Average Time（平均响应时刻为）”分不是47.115秒与26.648秒与93.983秒，从这三个数值来看，都过大，不符合要求。实际事物时刻应为

选择信息查询：93.983 /5/7 = 2.685 (除7做了7次点击选择信息)

注：除5 所有的事物都被重复执行5次

看完了“Average Time”，我们再看“90 Percent Time”，表示90%的事务

选择信息查询：146.797 /5/7 = 4.194 (除7做了7次点击选择信息)

注：除5 所有的事物都被重复执行5次

从图5- 7能够看出，所有Action平均事务响应时刻的趋势有较大的波动，因此使用“90 Percent Time”。按照上面的运算，此次测试结果记录如表5- 1所示。

测试项实际值是否通过

登录业务响应时刻14.142秒Y

批量查询响应时刻7.825秒Y

选择信息响应时刻 4.194秒Y

登录业务成功率100%

考勤业务成功率100%

登录查询总数1000

批量查询总数1000

选择信息总数1000

CPU使用率坚持100%

内存使用率<20%

表5- 1测试结果对比表一

每秒点击数

图5- 8显示的是“Hits per Second”与“Average Throughput (bytes/se cond)”的复合图，从图中能够看出，两种图形的曲线都正常同时差不多一致，讲明服务器能及时的同意客户端的要求，并能够返回结果。

图5- 8每秒点击数与每秒吞吐量复合图

业务成功率

。在“Transaction Summary”中我们能够专门明确的看到每个事务的执行状态，如图5- 9所示。

Color Scale Measurement

1 Pass

图5- 9事务状态统计图

从图中能够看出，所有的Aciton差不多上绿色的，即表示为Passed，同时除了vuser_init与vuser_end两个事务，其他的事务通过数为2163，也就表明在30分钟的时刻里，共完成了2163次登录考勤业务操作。那么按照这些能够判定此次测试登录业务与考勤业务的成功率是100%，再次更新测试结果记录表如表5- 2所示。

测试项实际值是否通过

登录业务响应时刻14.142秒Y

批量查询响应时刻7.825秒Y

选择信息响应时刻 4.194秒Y

登录业务成功率100% Y

考勤业务成功率100% Y

登录查询总数1000 Y

批量查询总数1000 Y

选择信息总数1000 Y

CPU使用率

内存使用率

表5- 2测试结果对比表二

系统资源

系统资源图显示了在场景执行过程中被监控的机器系统资源使用情形，一样情形下监控机器的CPU、内存、网络、磁盘等各个方面。此次测试监控的是测试服务器的CPU使用率与内存使用率，以及处理器队列长度，具体的数据如图5- 10所示。

Color Scale Measurement Min. Ave. Max. SD

1 % Processor Time (Processor _Total):192.168.0.108 4.167 63.813 91.406 7.081

0.1 Available MBytes (Memory):192.168.0.108 486 500.596 570 13.536

10 Processor Queue Length (System):192.168.0.108 0.0 1.962 31 3.204

图5- 10测试服务器系统资源监控结果图

从图中能够看出，CPU使用率、内存使用率、CPU的队列长度三个指标的曲线逗较为平滑，三者的平均值分不为：63.813 %、500.596、1.962，按照此次性能测试要求的：CPU使用率不超过75%,内存使用为130M。按照Windwos资源性能指标的讲明，一样情形下，如果“Processor Queue L ength（处理器队列长度）”一直超过二，则可能表示处理器堵塞，我们那个地点监控出来的数值是1.962接近2, 而且总体上保持平稳，那么由此推断，测试服务器的CPU也可能是个瓶颈。

获得上述数据后，最新的测试结果记录表如表5- 3所示。

测试项实际值是否通过

登录业务响应时刻14.142秒Y

批量查询响应时刻7.825秒Y

选择信息响应时刻 4.194秒Y

登录业务成功率100% Y

考勤业务成功率100% Y

登录查询总数1000 Y

批量查询总数1000 Y

选择信息总数1000 Y

CPU使用率63.813 %

内存使用率130M

表5- 3测试结果对比表三

从上表数据来看，此次测试总体上差不多达到了预期的性能指标，但从其他的数据，例如CPU的队列长度、内存使用率来看，被测服务器的硬件资源需要提升。通过tomcat 检测工具probe ,内存使用130M。

结论

测试中，系统在大量用户使用和长时刻反复运行中，系统未显现不良反应，包括cpu、内存占用过高、内存泄露等，系统反应良好，在大吞吐量情形系统响应时刻令人中意，系统稳固性比较可靠。

另：测试250到300用户的情形下系统表现情形。结果发觉系统在25 0 以上显现连接超时等现象，故在此次测试环境下并发用户峰值在250。