项目性能测试报告材料.docx

项目性能测试报告材料.docx

《项目性能测试报告材料.docx》由会员分享，可在线阅读，更多相关《项目性能测试报告材料.docx（27页珍藏版）》请在冰豆网上搜索。

项目性能测试报告材料

XXX项目or府门户网站性能测试报告

摘要

本文档主要描述XXXX网站检索和页面浏览性能测试中的测试内容、测试方法、测试策略等。

修改历史

日期

版本

作者

修改内容

评审号

更改请求号

2016-03-01

1.0

XXX测试组

新建。

性能测试

2016-03-02

1.0

XXX测试组

修改

性能测试回归

2016-03-02

1.0

XXX测试组

更新

注释：

评审号为评审记录表的编号。

更改请求号为文档更改控制工具自动生成的编号。

第一章概述

由于当前对系统要接受业务量的冲击，面临的系统稳定、成熟性方面的压力。

系统的性能问题必将成为焦点问题，海量数据量的“冲击”，系统能稳定在什么样的性能水平，面临业务增加时，系统抗压如何等这些问题需要通过一个较为真实的性能模拟测试来给出答案，通过测试和分析为系统性能的提升提供一些重要参考数据，以供后期系统在软硬件方面的改善和完善。

本《性能测试报告》即是基于上述考虑，参考当前的一些性能测试方法而编写的，用以指导即将进行的该系统性能测试。

第二章测试活动

2.1测试用具

本次性能测试主要采用HP公司的Loadrunner11作为性能测试工具。

Loadrunner主要提供了3个性能测试组件：

VirtualUserGenerator,Controller,Analysis。

●使用VirtualUserGenerator修改和优化脚本。

●使用Controller进行管理，控制并发的模拟并发数，记录测试结果。

●使用Analysis进行统计和分析结果。

2.2测试范围

此次性能测试实施是对吴忠市门户网站系统性能进行测试评估的过程，我们将依据系统将来的实际运行现状，结合系统的设计目标和业务特点，遵循着发生频率高、对系统或数据库性能影响大、关键和核心业务等原则选取需要进行测试的业务，模拟最终用户的操作行为，构建一个与生产环境相近的压力场景，对系统实施压力测试，以此评判系统的实际性能表现。

根据与相关设计，开发人员的沟通和交流，本次测试主要就是针对大量用户在使用吴忠市门户网站进行信息查询，而选取的典型事务就是用户使用检索进行关键字搜索以及界面浏览和反馈回搜索结果，这是用户使用最频繁，反应最多的地方，也是本系统当前以及以后业务的一个重要压力点所在。

所以本次测试只选取检索业务的性能情况和界面浏览进行记录和分析。

2.3测试目标

本次测试是针对陕西门户网站检索和页面浏览在迎接大业务量的压力下而进行的，主要需要获得如下的测试指标。

1、系统的稳定负载能力：

即在正常的响应时间中，系统能够支持的最多的客户端的数量，例如：

找到用户可容忍的基本响应时间为5--8秒时，系统的支持用户数。

2、系统的极限负载能力：

即在某个较长的响应时间，客户主观上已无法容忍的情况下，系统能够支持的最多的客户端的数量。

3、系统的无故障运行时间：

即在得出系统的最合理的响应时间和支持响应的客户端数量该前提下，无故障运行时间，暂定8--15小时。

2.4测试方法

总体方法：

使用美科利公司（Mercury）的性能测试软件LoadRunner，对现行的系统检索，页面预览进行脚本录制、测试回放、逐步加压和跟踪记录。

测试过程中，由LoadRunner的管理平台调用各台测试前台，发起检索查询请求，并跟踪记录服务器端的运行情况和返回给客户端的运行结果。

此次性能测试在XXXXXXX进行，环境在服务器软件、硬件上与生产环境保持一致，数据库结构和真实环境数据库结构一致，只是在网络带宽上有一定的区别，实际外网带宽会有所不足。

本次将进行基准测试，并发数测试，稳定性测试3种类型测试，并对主要测试指标进行记录和分析。

2.4.1基准测试

基准测试在系统无压力（外界环境，服务器无额外服务运行，无额外监控进程运行）的情况下，取得各项事务和业务的系统并发用户数和平均响应时间作为分析衡量标准，用于初步诊断系统是否存在性能瓶颈。

2.4.2并发测试

没有明确的系统性能指标前提下，用Loadrunner模拟多用户同时向服务器发起交易请求，运行过程中每个用户没有思考时间（ThinkTime）的情况下持续提交交易请求，向系统施加压力。

2.4.3稳定性测试

重点测试支付系统在业务高峰期压力下运行的稳定性。

2.5性能指标

在本次性能测试，由于没有具体和明确的性能指标，所以各类测试指标包括测试中应该达到的某些性能指标和相关服务器的性能指标，都应该受到以下三个基本条件的约束。

Ø业务执行的平均响应时间（期望值：

<=8s）

ØCPU利用率小于75%

Ø内存Pagingrate状态未持续处于高位运行

2.6性能测试流程

通过自动化测试工具模拟最终用户向服务器发起业务请求，进行性能测试。

通过测试工具对测试过程中系统各点进行监控，每一次测试结束后工具自动生成结果报告供分析使用。

2.7测试术语

1）系统的响应时间：

即在各种负载压力情况下，系统的响应时间，也就是从客户端交易发起，到服务器端交易应答返回所需要的时间，包括网络传输时间和服务器处理时间。

2）应用系统的吞吐量：

即应用系统在单位时间内完成的交易量，也就是在单位时间内，应用系统针对不同的负载压力，所能完成的交易数量。

3）应用系统的负载能力：

即系统所能容忍的最大用户数量，也就是在正常的响应时间中，系统能够支持的最多的客户端的数量。

4）缩略语：

Vuser，Transaction，TPS

Vuser虚拟用户Virtualuser,模拟真实业务逻辑步骤的虚拟用户,虚拟用户模拟的操作步骤都被记录在虚拟用户脚本里。

Vuser脚本用于描述Vuser在场景中执行的操作。

Transaction事务事务是性能测试脚本的一个重要特性。

要度量服务器的性能,需要定义事务,每个事务都包含事务开始和事务结束标记。

事务用来衡量脚本中一行代码或多行代码的执行所耗费的时间.可以将事务开始放置在脚本中某行或者多行代码的前面,将事务结束放置在该行或者多行代码的后面,在该脚本的虚拟用户运行时,这个事务将衡量该行或者多行代码的执行花费了多长时间。

TPS每秒事务数（TransactionPerSecond）每秒钟系统能够处理的交易或事务的数量,它是衡量系统处理能力的重要指标。

TPS是LoadRunner中重要的性能参数指标。

第三章性能测试环境

3.1服务器环境

互动服务器：

服务器型号：

虚拟化

CPU：

4核intel（R）Xeon（R）CPU2.40GHz

内存：

8GB

系统盘：

云硬盘

数据盘：

云硬盘500GB

操作系统：

Centos7.0-64bit

应用软件：

tomcat7.0

WEB服务器：

服务器型号：

虚拟化

CPU：

8核intel（R）Xeon（R）CPU2.40GHz

内存：

16GB

系统盘：

云硬盘

数据盘：

云硬盘500GB

操作系统：

Centos7.0-64bit

应用软件：

apache2.4.17

内容管理服务器：

服务器型号：

虚拟化

CPU：

8核intel（R）Xeon（R）CPU2.40GHz

内存：

16GB

系统盘：

云硬盘

数据盘：

云硬盘500GB

操作系统：

Centos7.0-64bit

应用软件：

tomcat7.0

用户中心服务器：

服务器型号：

虚拟化

CPU：

8核intel（R）Xeon（R）CPU2.40GHz

内存：

16GB

系统盘：

云硬盘

数据盘：

云硬盘500GB

操作系统：

Centos7.0-64bit

应用软件：

tomcat7.0

智能检索服务器：

服务器型号：

虚拟化

CPU：

8核intel（R）Xeon（R）CPU2.40GHz

内存：

16GB

系统盘：

云硬盘

数据盘：

云硬盘500GB

操作系统：

windows2008_X64

应用软件：

tomcat7.0

3.2客户端环境

资源

描述

数量

Loadrunner11

主要性能测试工具

1

Office2007

用于记录测试数据

2

WindowsXPSP3,Windows7

测试客户端系统

1

IE10，Firefox及其组件

测试客户端应用软件

1

PC

测试计算机

2

3.3网络结构

网络拓扑和结构图如下：

第四章测试方案

本次性能测试主要模拟测试的事务：

用户信息浏览检索

用户提交查询关键字数据到后台，系统收到查询请求并检索、返回结果数据；

●性能测试观察指标：

　　Bs结构程序一般会关注的通用指标如下：

　　Web服务器指标指标：

　　*AvgRps:

平均每秒钟响应次数=总请求时间/秒数；

　　*SuccessfulRounds：

成功的请求；

　　*FailedRounds：

失败的请求；

　　*SuccessfulHits：

成功的点击次数；

　　*FailedHits：

失败的点击次数；

　　*HitsPerSecond：

每秒点击次数；

　　*SuccessfulHitsPerSecond：

每秒成功的点击次数；

　　*FailedHitsPerSecond：

每秒失败的点击次数；

　　*AttemptedConnections：

尝试链接数；

●执行每个场景时记录以下相应的数据：

Ø业务执行的平均响应时间

Ø每秒事务数

Ø运行的并发用户数目

Ø网络吞吐量

4.1基准测试

场景：

（历史数据有1000条以上）

1.使用Loadrunner模拟100用户请求（时间5分钟），每个用户没有时间间隔（ThinkTime）的情况下反复提交交易并返回结果，直到全部执行退出系统。

记录平均事务响应时间，每秒事务数，吞吐量。

2.记并发数改为200（10分钟），同时加压，同时结束压力，重复上述测试步骤。

3.并发数改为300（30分钟），重复上述测试步骤。

4.当响应时间大于期望时间，或者服务器指标超过预订设置时将停止测试。

备注：

以上测试均进行3次，来保证测试结果的有效性和准确性。

4.2并发测试

场景：

（历史数据有1000条以上）

1.使用Loadrunner模拟300用户请求交易，每个用户没有时间间隔（ThinkTime）的情况下反复提交交易并返回结果，持续时间分别为10分钟，20分钟，30分钟，记录平均事务响应时间，每秒事务数，吞吐量。

2.记并发数改为500重复上述测试步骤。

3.并发数改为700，重复上述测试步骤。

4.当响应时间大于期望时间，或者服务器指标超过预期设置时将停止测试。

备注：

以上测试均进行3次，来保证测试结果的有效性和准确性。

3次执行时间分别为10分钟，20分钟，30分钟。

4.3稳定性测试

测试方法：

采用业务中合理、适度的用户使用场景，对系统进行时间为8--12小时的稳定性测试。

记录每次服务的平均响应时间，交易的正确率，考察服务器是否宕机，交易正确率小于95%等情况。

稳定性测试的用例如下：

场景：

（历史数据有1000条以上）

1.使用Loadrunner模拟50个并发用户请求交易，每个用户有一定时间间隔（ThinkTime）1秒的情况下反复点击页面和信息检索并返回结果，持续执行8--12小时（2016-3-1-17:

30---2016-3-2-8:

30）每秒5次以上的点击和检索，记录平均事务响应时间，每秒事务数，吞吐量。

观察软件的稳定性以及各种性能指标的劣化趋势，要有效防止资源泄露。

2.当服务器出现资源泄露或者系统的资源耗尽等情况，点击正确率小于95%，停止测试。

第五章测试结果描述和分析

6.1基准测试性能分析

设计100、200、300个用户并发，没有持续加压时间，直至执行完成。

获取系统的各种表现。

100个用户的测试信息统计：

200个用户的测试信息统计：

1、事务平均响应时间

序号

单项事务

用户数响应时间（s）

备注

100

200

300

总流程时间

5.643

5.777

8.594

100个用户的响应时间：

200个用户的响应时间：

从以上图中可以看出，服务器在100，200个并发的情况下所有事务都保持在5s左右，但稍微高于5s，应该有一定的上升空间。

最大的问题在于并发数200后，处理时间已经在5s以上，达到10s。

建议：

优化请求响应模块以及检索应用模块或者网络，减少响应时间。

2、TPS（事务数/秒）

100个用户的每秒事务数：

200个用户的每秒事务数：

从以上每个图中看到TPS达到峰值1后开始有下降的趋势，基本上均在1个事物以下，这个数据并不理想，我们服务器的性能还没有充分发挥，现有硬件条件下还可以在单位时间内处理更多的事务数，建议在下一阶段进行优化提升。

或者是网络不佳的情况导致该情况的出现。

3、吞吐量

并发数

TotalThroughput（bytes）

AverageThroughput

（bytes/second）

100

1220186.625

487637.735

200

1008981.375

828085.166

100个用户的吞吐量：

200个用户的吞吐量：

从图中可以看出总吞吐量随着用户的增加成正比的，数据交换正常。

但是，在对网络带宽，系统架构，硬件资源的合理分配后应该能发挥系统的更大处理能力。

6.2并发测试性能分析

设计300、500、700个用户并发，分别持续10分钟，20分钟，30分钟，40分钟获取系统的各种表现。

300个用户并发的测试统计信息（以30分钟为例）：

500个用户并发的测试统计信息（以40分钟为例）：

700个用户并发的测试统计信息（以40分钟为例）：

1、平均事务响应时间

测试用例

响应时间（单位：

秒）

并发100持续5分钟

14.009

并发100持续10分钟

15.31

并发100持续30分钟

11.178

并发200持续5分钟

16.318

并发200持续10分钟

14.143

并发200持续40分钟

15.675

并发300持续5分钟

24.859

并发300持续10分钟

24.997

并发300持续40分钟

26.349

300个并发（以10分钟为例）：

500个并发（以10分钟为例）：

700个并发（以10分钟为例）：

从图中看出，并发用户数同时进行5分钟，响应时间就已经在10s以上了，随着并发用户数和持续时间的增加，响应时间变得越来越长，当200个并发的时候已经超过20秒，已经相对较慢，但是这只是实验室理论测试数据，在实际生产环境中过高的并发数和过长的持续压力时间这种极端情况很少。

但是并发持续了5分钟这种情况下，我们的响应时间还是应该可以控制在8秒以内，使我们系统在较大的业务量的情况下可以提供较为满意的用户体验。

导致这样的一种情况主要来自于网络不佳造成（该问题并不是由于服务器端的网络不良，而是来自用户端的网络不佳导致）

2、TPS（事务数/秒）（以10分钟为例）

测试用例

TPS

并发300持续10分钟

3.086

并发500持续10分钟

6.260

并发700持续10分钟

7.184

300个并发（以10分钟为例）：

500个并发（以10分钟为例）：

700个并发（以10分钟为例）：

TPS数值并不理想，它反映了服务器处理能力一般，没有充分发挥应用服务器的事务处理能力。

建议：

在下一个阶段需要优化。

但是这个原因可能是由于网络带宽、前置接入系统处理能力较小，比如：

连接数有所限制，所以最后到达核心应用服务器事务数较小，连锁导致最终事务处理能力上不去。

3、吞吐量（以10分钟为例）

测试用例

TotalThroughput（bytes）

AverageThroughput（bytes/second）

并发100持续10分钟

3,628,897,747

5,416,265

并发200持续10分钟

7,096,275,509

10,008,851

并发300持续10分钟

8,262,379,069

11,120,295

300个并发（以10分钟为例）：

500个并发（以10分钟为例）：

700个并发（以10分钟为例）：

在运行相同时间的前提条件下，随着用户翻倍的增加吞吐量没有明显增加。

初步怀疑：

网络带宽的限制，或者是前置接入系统的处理能力问题，请求并没有发送到核心应用服务器端去及时处理。

6.3稳定性性能测试分析

本次测试使用Loadrunner模拟50用户请求交易，每个用户没有时间间隔（ThinkTime）的情况下反复提交交易并返回结果，持续执行8--12小时。

1、事务平均响应时间

总流程

响应时间

本次稳定性测试各个服务器没有出现宕机的情况，交易的正确率为99.99%。

但是响应时间稍稍有点长了些，可以有进一步调优的空间，一般控制在8s以下为佳（导致响应时间较长主要来自于用户端网络不佳的情况导致并非服务器端的网络不佳）。

第六章测试结论