《项目性能测试报告.pdf》由会员分享,可在线阅读,更多相关《项目性能测试报告.pdf(29页珍藏版)》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、 XXX 项目 or 府门户网站性能测试报告 目录 第一章 概述.错误!未定义书签。第二章 测试活动.错误!未定义书签。测试用具.错误!未定义书签。测试范围.错误!未定义书签。测试目标.错误!未定义书签。测试方法.错误!未定义书签。基准测试.错误!未定义书签。并发测试.错误!未定义书签。稳定性测试.错误!未定义书签。性能指标.错误!未定义书签。性能测试流程.错误!未定义书签。测试术语.错误!未定义书签。第三章 性能测试环境.错误!未定义书签。服务器环境.错误!未定义书签。客户端环境.错误!未定义书签。网络结构.错误!未定义书签。第四章 测试方案.错误!未定义书签。基准测试.错误!未定义书签。并
2、发测试.错误!未定义书签。稳定性测试.错误!未定义书签。第五章 测试结果描述和分析.错误!未定义书签。基准测试性能分析.错误!未定义书签。并发测试性能分析.错误!未定义书签。稳定性性能测试分析.错误!未定义书签。第六章 测试结论.错误!未定义书签。摘要 本文档主要描述 XXXX 网站检索和页面浏览性能测试中的测试内容、测试方法、测试策略等。修改历史 日期 版本 作者 修改内容 评审号 更改请求号 2016-03-01 XXX 测试组 新建。性能测试 2016-03-02 XXX 测试组 修改 性能测试回归 2016-03-02 XXX 测试组 更新 注释:评审号为评审记录表的编号。更改请求号为
3、文档更改控制工具自动生成的编号。第一章 概述 由于当前对系统要接受业务量的冲击,面临的系统稳定、成熟性方面的压力。系统的性能问题必将成为焦点问题,海量数据量的“冲击”,系统能稳定在什么样的性能水平,面临业务增加时,系统抗压如何等这些问题需要通过一个较为真实的性能模拟测试来给出答案,通过测试和分析为系统性能的提升提供一些重要参考数据,以供后期系统在软硬件方面的改善和完善。本性能测试报告即是基于上述考虑,参考当前的一些性能测试方法而编写的,用以指导即将进行的该系统性能测试。第二章 测试活动 测试用具 本次性能测试主要采用 HP 公司的 Loadrunner11 作为性能测试工具。Load runn
4、er 主要提供了 3 个性能测试组件:Virtual User Generator,Controller,Analysis。使用 Virtual User Generator 修改和优化脚本。使用 Controller 进行管理,控制并发的模拟并发数,记录测试结果。使用 Analysis 进行统计和分析结果。测试范围 此次性能测试实施是对吴忠市门户网站系统性能进行测试评估的过程,我们将依据系统将来的实际运行现状,结合系统的设计目标和业务特点,遵循着发生频率高、对系统或数据库性能影响大、关键和核心业务等原则选取需要进行测试的业务,模拟最终用户的操作行为,构建一个与生产环境相近的压力场景,对系统实
5、施压力测试,以此评判系统的实际性能表现。根据与相关设计,开发人员的沟通和交流,本次测试主要就是针对大量用户在使用吴忠市门户网站进行信息查询,而选取的典型事务就是用户使用检索进行关键字搜索以及界面浏览和反馈回搜索结果,这是用户使用最频繁,反应最多的地方,也是本系统当前以及以后业务的一个重要压力点所在。所以本次测试只选取检索业务的性能情况和界面浏览进行记录和分析。测试目标 本次测试是针对陕西门户网站检索和页面浏览在迎接大业务量的压力下而进行的,主要需要获得如下的测试指标。1、系统的稳定负载能力:即在正常的响应时间中,系统能够支持的最多的客户端的数量,例如:找到用户可容忍的基本响应时间为 5-8 秒
6、时,系统的支持用户数。2、系统的极限负载能力:即在某个较长的响应时间,客户主观上已无法容忍的情况下,系统能够支持的最多的客户端的数量。3、系统的无故障运行时间:即在得出系统的最合理的响应时间和支持响应的客户端数量该前提下,无故障运行时间,暂定 8-15 小时。测试方法 总体方法:使用美科利公司(Mercury)的性能测试软件 Load Runner,对现行的系统检索,页面预览进行脚本录制、测试回放、逐步加压和跟踪记录。测试过程中,由 Load Runner的管理平台调用各台测试前台,发起检索查询请求,并跟踪记录服务器端的运行情况和返回给客户端的运行结果。此次性能测试在 XXXXXXX 进行,环
7、境在服务器软件、硬件上与生产环境保持一致,数据库结构和真实环境数据库结构一致,只是在网络带宽上有一定的区别,实际外网带宽会有所不足。本次将进行基准测试,并发数测试,稳定性测试 3 种类型测试,并对主要测试指标进行记录和分析。基准测试 基准测试在系统无压力(外界环境,服务器无额外服务运行,无额外监控进程运行)的情况下,取得各项事务和业务的系统并发用户数和平均响应时间作为分析衡量标准,用于初步诊断系统是否存在性能瓶颈。并发测试 没有明确的系统性能指标前提下,用 Load runner 模拟多用户同时向服务器发起交易请求,运行过程中每个用户没有思考时间(Think Time)的情况下持续提交交易请求
8、,向系统施加压力。稳定性测试 重点测试支付系统在业务高峰期压力下运行的稳定性。性能指标 在本次性能测试,由于没有具体和明确的性能指标,所以各类测试指标包括测试中应该达到的某些性能指标和相关服务器的性能指标,都应该受到以下三个基本条件的约束。业务执行的平均响应时间(期望值:=8s)CPU 利用率小于 75%内存 Paging rate 状态未持续处于高位运行 性能测试流程 通过自动化测试工具模拟最终用户向服务器发起业务请求,进行性能测试。通过测试工具对测试过程中系统各点进行监控,每一次测试结束后工具自动生成结果报告供分析使用。测试术语 1)系统的响应时间:即在各种负载压力情况下,系统的响应时间,
9、也就是从客户端交易发起,到服务器端交易应答返回所需要的时间,包括网络传输时间和服务器处理时间。2)应用系统的吞吐量:即应用系统在单位时间内完成的交易量,也就是在单位时间内,应用系统针对不同的负载压力,所能完成的交易数量。3)应用系统的负载能力:即系统所能容忍的最大用户数量,也就是在正常的响应时间中,系统能够支持的最多的客户端的数量。4)缩略语:Vuser,Transaction,TPS Vuser 虚拟用户 Virtual user,模拟真实业务逻辑步骤的虚拟用户,虚拟用户模拟的操作步骤都被记录在虚拟用户脚本里。Vuser 脚本用于描述 Vuser 在场景中执行的操作。Transaction
10、事务 事务是性能测试脚本的一个重要特性。要度量服务器的性能,需要定义事务,每个事务都包含事务开始和事务结束标记。事务用来衡量脚本中一行代码或多行代码的执行所耗费的时间.可以将事务开始放置在脚本中某行或者多行代码的前面,将事务结束放置在该行或者多行代码的后面,在该脚本的虚拟用户运行时,这个事务将衡量该行或者多行代码的执行花费了多长时间。TPS 每秒事务数(Transaction Per Second)每秒钟系统能够处理的交易或事务的数量,它是衡量系统处理能力的重要指标。TPS 是 Load Runner 中重要的性能参数指标。第三章 性能测试环境 服务器环境 互动服务器:服务器型号:虚拟化 CP
11、U:4 核 intel(R)Xeon(R)CPU 内存:8GB 系统盘:云硬盘 数据盘:云硬盘 500GB 操作系统:应用软件:tomcat WEB 服务器:服务器型号:虚拟化 CPU:8 核 intel(R)Xeon(R)CPU 内存:16GB 系统盘:云硬盘 数据盘:云硬盘 500GB 操作系统:应用软件:apache 内容管理服务器:服务器型号:虚拟化 CPU:8 核 intel(R)Xeon(R)CPU 内存:16GB 系统盘:云硬盘 数据盘:云硬盘 500GB 操作系统:应用软件:tomcat 用户中心服务器:服务器型号:虚拟化 CPU:8 核 intel(R)Xeon(R)CPU
12、内存:16GB 系统盘:云硬盘 数据盘:云硬盘 500GB 操作系统:应用软件:tomcat 智能检索服务器:服务器型号:虚拟化 CPU:8 核 intel(R)Xeon(R)CPU 内存:16GB 系统盘:云硬盘 数据盘:云硬盘 500GB 操作系统:windows2008_X64 应用软件:tomcat 客户端环境 资源 描述 数量 Load runner 11 主要性能测试工具 1 Office 2007 用于记录测试数据 2 Windows XP SP3,Windows7 测试客户端系统 1 IE10,Firefox 及其组件 测试客户端应用软件 1 PC 测试计算机 2 网络结构 网
13、络拓扑和结构图如下:第四章 测试方案 本次性能测试主要模拟测试的事务:用户信息浏览检索 用户提交查询关键字数据到后台,系统收到查询请求并检索、返回结果数据;性能测试观察指标:Bs 结构程序一般会关注的通用指标如下:Web 服务器指标指标:*Avg Rps:平均每秒钟响应次数=总请求时间/秒数;*Successful Rounds:成功的请求;*Failed Rounds:失败的请求;*Successful Hits:成功的点击次数;*Failed Hits:失败的点击次数;*Hits Per Second:每秒点击次数;*Successful Hits Per Second:每秒成功的点击次数
14、;*Failed Hits Per Second:每秒失败的点击次数;*Attempted Connections:尝试链接数;执行每个场景时记录以下相应的数据:业务执行的平均响应时间 每秒事务数 运行的并发用户数目 网络吞吐量 基准测试 场景:(历史数据有 1000 条以上)1.使用 Load runner 模拟 100 用户请求(时间 5 分钟),每个用户没有时间间隔(Think Time)的情况下反复提交交易并返回结果,直到全部执行退出系统。记录平均事务响应时间,每秒事务数,吞吐量。2.记并发数改为 200(10 分钟),同时加压,同时结束压力,重复上述测试步骤。3.并发数改为 300(
15、30 分钟),重复上述测试步骤。4.当响应时间大于期望时间,或者服务器指标超过预订设置时将停止测试。备注:以上测试均进行 3 次,来保证测试结果的有效性和准确性。并发测试 场景:(历史数据有 1000 条以上)1.使用 Loadrunner 模拟 300 用户请求交易,每个用户没有时间间隔(ThinkTime)的情况下反复提交交易并返回结果,持续时间分别为 10 分钟,20 分钟,30 分钟,记录平均事务响应时间,每秒事务数,吞吐量。2.记并发数改为 500 重复上述测试步骤。3.并发数改为 700,重复上述测试步骤。4.当响应时间大于期望时间,或者服务器指标超过预期设置时将停止测试。备注:以
16、上测试均进行 3 次,来保证测试结果的有效性和准确性。3 次执行时间分别为 10 分钟,20 分钟,30 分钟。稳定性测试 测试方法:采用业务中合理、适度的用户使用场景,对系统进行时间为 8-12 小时的稳定性测试。记录每次服务的平均响应时间,交易的正确率,考察服务器是否宕机,交易正确率小于 95%等情况。稳定性测试的用例如下:场景:(历史数据有 1000 条以上)1.使用 Loadrunner 模拟 50 个并发用户请求交易,每个用户有一定时间间隔(ThinkTime)1 秒的情况下反复 点击页面和信息检索并返回结果,持续执行 8-12 小时(2016-3-1-17:30-2016-3-2-
17、8:30)每秒 5 次以上的点击和检索,记录平均事务响应时间,每秒事务数,吞吐量。观察软件的稳定性以及各种性能指标的劣化趋势,要有效防止资源泄露。2.当服务器出现资源泄露或者系统的资源耗尽等情况,点击正确率小于 95%,停止测试。第五章 测试结果描述和分析 基准测试性能分析 设计 100、200、300 个用户并发,没有持续加压时间,直至执行完成。获取系统的各种表现。100 个用户的测试信息统计:200 个用户的测试信息统计:1、事务平均响应时间 序号 单项事务 用户数响应时间(s)备注 100 200 300 总流程时间 100 个用户的响应时间:200 个用户的响应时间:从以上图中可以看出
18、,服务器在 100,200 个并发的情况下所有事务都保持在 5s 左右,但稍微高于 5s,应该有一定的上升空间。最大的问题在于并发数 200 后,处理时间已经在5s 以上,达到 10s。建议:优化请求响应模块以及检索应用模块或者网络,减少响应时间。2、TPS(事务数/秒)100 个用户的每秒事务数:200 个用户的每秒事务数:从以上每个图中看到 TPS 达到峰值 1 后开始有下降的趋势,基本上均在 1 个事物以下,这个数据并不理想,我们服务器的性能还没有充分发挥,现有硬件条件下还可以在单位时间内处理更多的事务数,建议在下一阶段进行优化提升。或者是网络不佳的情况导致该情况的出现。3、吞吐量 并发
19、数 Total Throughput(bytes)Average Throughput(bytes/second)100 200 100 个用户的吞吐量:200 个用户的吞吐量:从图中可以看出总吞吐量随着用户的增加成正比的,数据交换正常。但是,在对网络带宽,系统架构,硬件资源的合理分配后应该能发挥系统的更大处理能力。并发测试性能分析 设计 300、500、700 个用户并发,分别持续 10 分钟,20 分钟,30 分钟,40 分钟获取系统的各种表现。300 个用户并发的测试统计信息(以 30 分钟为例):500 个用户并发的测试统计信息(以 40 分钟为例):700 个用户并发的测试统计信息(
20、以 40 分钟为例):1、平均事务响应时间 测试用例 响应时间(单位:秒)并发 100 持续 5 分钟 并发 100 持续 10 分钟 并发 100 持续 30 分钟 并发 200 持续 5 分钟 并发 200 持续 10 分钟 并发 200 持续 40 分钟 并发 300 持续 5 分钟 并发 300 持续 10 分钟 并发 300 持续 40 分钟 300 个并发(以 10 分钟为例):500 个并发(以 10 分钟为例):700 个并发(以 10 分钟为例):从图中看出,并发用户数同时进行 5 分钟,响应时间就已经在 10s 以上了,随着并发用户数和持续时间的增加,响应时间变得越来越长,
21、当 200 个并发的时候已经超过 20 秒,已经相对较慢,但是这只是实验室理论测试数据,在实际生产环境中过高的并发数和过长的持续压力时间这种极端情况很少。但是并发持续了 5 分钟这种情况下,我们的响应时间还是应该可以控制在 8 秒以内,使我们系统在较大的业务量的情况下可以提供较为满意的用户体验。导致这样的一种情况主要来自于网络不佳造成(该问题并不是由于服务器端的网络不良,而是来自用户端的网络不佳导致)2、TPS(事务数/秒)(以 10 分钟为例)测试用例 TPS 并发 300 持续 10 分钟 并发 500 持续 10 分钟 并发 700 持续 10 分钟 300 个并发(以 10 分钟为例)
22、:500 个并发(以 10 分钟为例):700 个并发(以 10 分钟为例):TPS 数值并不理想,它反映了服务器处理能力一般,没有充分发挥应用服务器的事务处理能力。建议:在下一个阶段需要优化。但是这个原因可能是由于网络带宽、前置接入系统处理能力较小,比如:连接数有所限制,所以最后到达核心应用服务器事务数较小,连锁导致最终事务处理能力上不去。3、吞吐量(以 10 分钟为例)测试用例 Total Throughput(bytes)Average Throughput(bytes/second)并发 100 持续 10 分钟 3,628,897,747 5,416,265 并发 200 持续 10
23、 分钟 7,096,275,509 10,008,851 并发 300 持续 10 分钟 8,262,379,069 11,120,295 300 个并发(以 10 分钟为例):500 个并发(以 10 分钟为例):700 个并发(以 10 分钟为例):在运行相同时间的前提条件下,随着用户翻倍的增加吞吐量没有明显增加。初步怀疑:网络带宽的限制,或者是前置接入系统的处理能力问题,请求并没有发送到核心应用服务器端去及时处理。稳定性性能测试分析 本次测试使用Loadrunner模拟50用户请求交易,每个用户没有时间间隔(ThinkTime)的情况下反复提交交易并返回结果,持续执行 8-12 小时。1、事务平均响应时间 总流程 响应时间 本次稳定性测试各个服务器没有出现宕机的情况,交易的正确率为%。但是响应时间稍稍有点长了些,可以有进一步调优的空间,一般控制在 8s 以下为佳(导致响应时间较长主要来自于用户端网络不佳的情况导致并非服务器端的网络不佳)。第六章 测试结论