文档库

最新最全的文档下载
当前位置:文档库 > 项目性能测试报告

项目性能测试报告

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客户端环境 (9)

3.3网络结构 (9)

第四章测试方案 (10)

4.1基准测试 (11)

4.2并发测试 (13)

4.3稳定性测试 (15)

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

6.1基准测试性能分析 (16)

6.2并发测试性能分析 (21)

6.3稳定性性能测试分析 (28)

第六章测试结论 (29)

摘要

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

修改历史

项目性能测试报告

第一章概述

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

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

第二章测试活动

2.1测试用具

本次性能测试主要采用HP公司的Loadrunner11作为性能测试工具。Load runner主要提供了3个性能测试组件:Virtual User Generator, Controller,Analysis。

●使用Virtual User Generator修改和优化脚本。

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

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

2.2测试范围

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

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

分析。

2.3测试目标

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

1、系统的稳定负载能力:即在正常的响应时间中,系统能够支持的最多的客户端的数量,例如:找到用户可容忍的基本响应时间为5--8秒时,系统的支持用户数。

2、系统的极限负载能力:即在某个较长的响应时间,客户主观上已无法容忍的情况下,系统能够支持的最多的客户端的数量。

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

2.4测试方法

总体方法:使用美科利公司(Mercury)的性能测试软件Load Runner,对现行的系统检索,页面预览进行脚本录制、测试回放、逐步加压和跟踪记录。测试过程中,由Load Runner的管理平台调用各台测试前台,发起检索查询请求,并跟踪记录服务器端的运行情况和返回给客户端的运行结果。

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

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

2.4.1基准测试

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

2.4.2并发测试

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

2.4.3稳定性测试

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

2.5性能指标

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

业务执行的平均响应时间(期望值:<= 8s)

CPU利用率小于75%

内存Paging rate状态未持续处于高位运行

2.6性能测试流程

通过自动化测试工具模拟最终用户向服务器发起业务请求,进行性能测试。通过测试工具对测试过程中系统各点进行监控,每一次测试结束后工具自动生成结果报告供分析使用。

项目性能测试报告

2.7测试术语

1)系统的响应时间:即在各种负载压力情况下,系统的响应时间,也就是从客户端

交易发起,到服务器端交易应答返回所需要的时间,包括网络传输时间和服务器

处理时间。

2)应用系统的吞吐量:即应用系统在单位时间内完成的交易量,也就是在单位时间

内,应用系统针对不同的负载压力,所能完成的交易数量。

3)应用系统的负载能力:即系统所能容忍的最大用户数量,也就是在正常的响应时

间中,系统能够支持的最多的客户端的数量。

4)缩略语:Vuser,Transaction,TPS

Vuser虚拟用户Virtual user,模拟真实业务逻辑步骤的虚拟用户,虚拟用户模拟的

操作步骤都被记录在虚拟用户脚本里。Vuser 脚本用于描述Vuser 在场景中执

行的操作。

Transaction事务事务是性能测试脚本的一个重要特性。要度量服务器的性能,

需要定义事务,每个事务都包含事务开始和事务结束标记。事务用来衡量脚本中一

行代码或多行代码的执行所耗费的时间.可以将事务开始放置在脚本中某行或者

多行代码的前面,将事务结束放置在该行或者多行代码的后面,在该脚本的虚拟用

户运行时,这个事务将衡量该行或者多行代码的执行花费了多长时间。

TPS每秒事务数(Transaction Per Second) 每秒钟系统能够处理的交易或事务的

数量,它是衡量系统处理能力的重要指标。TPS 是Load Runner 中重要的性能参

数指标。

第三章性能测试环境

3.1服务器环境

互动服务器:

服务器型号:虚拟化

CPU:4核intel(R) Xeon(R) CPU 2.40GHz

内存:8GB

系统盘:云硬盘

数据盘:云硬盘500GB

操作系统:Centos7.0-64bit

应用软件:tomcat 7.0

WEB服务器:

服务器型号:虚拟化

CPU:8核intel(R) Xeon(R) CPU 2.40GHz

内存:16GB

系统盘:云硬盘

数据盘:云硬盘500GB

操作系统:Centos7.0-64bit

应用软件:apache 2.4.17

内容管理服务器:

服务器型号:虚拟化

CPU:8核intel(R) Xeon(R) CPU 2.40GHz

内存:16GB

系统盘:云硬盘

数据盘:云硬盘500GB

操作系统:Centos7.0-64bit

应用软件:tomcat 7.0

用户中心服务器:

服务器型号:虚拟化

CPU:8核intel(R) Xeon(R) CPU 2.40GHz

内存:16GB

系统盘:云硬盘

数据盘:云硬盘500GB

操作系统:Centos7.0-64bit

应用软件:tomcat 7.0

智能检索服务器:

服务器型号:虚拟化

CPU:8核intel(R) Xeon(R) CPU 2.40GHz 内存:16GB

系统盘:云硬盘

数据盘:云硬盘500GB

操作系统:windows2008_X64

应用软件:tomcat 7.0

3.2客户端环境

项目性能测试报告

3.3网络结构

网络拓扑和结构图如下:

项目性能测试报告

第四章测试方案

本次性能测试主要模拟测试的事务:用户信息浏览检索

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

性能测试观察指标:

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

Web服务器指标指标:

* Avg Rps: 平均每秒钟响应次数=总请求时间/ 秒数;

* Successful Rounds:成功的请求;

* Failed Rounds :失败的请求;

* Successful Hits :成功的点击次数;

* Failed Hits :失败的点击次数;

* Hits Per Second :每秒点击次数;

* Successful Hits Per Second :每秒成功的点击次数;

* Failed Hits Per Second :每秒失败的点击次数;

* Attempted Connections :尝试链接数;

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

业务执行的平均响应时间

每秒事务数

运行的并发用户数目

网络吞吐量

4.1基准测试

场景:(历史数据有1000条以上)

1.使用Load runner模拟100用户请求(时间5分钟),每个用户没有时间间隔(Think

Time)的情况下反复提交交易并返回结果,直到全部执行退出系统。记录平均事务响应时间,每秒事务数,吞吐量。

项目性能测试报告

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、事务平均响应时间

项目性能测试报告

100个用户的响应时间:

项目性能测试报告

200个用户的响应时间:

项目性能测试报告

从以上图中可以看出,服务器在100,200个并发的情况下所有事务都保持在5s左右,但稍微高于5s,应该有一定的上升空间。最大的问题在于并发数200后,处理时间已经在5s以上,达到10s。建议:优化请求响应模块以及检索应用模块或者网络,减少响应时间。

2、TPS (事务数/秒)

100个用户的每秒事务数:

项目性能测试报告

200个用户的每秒事务数:

项目性能测试报告

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

3、吞吐量

项目性能测试报告

100个用户的吞吐量: