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