负载均衡性能评估第一阶段总结报告v1.0

《负载均衡性能评估第一阶段总结报告v1.0》由会员分享，可在线阅读，更多相关《负载均衡性能评估第一阶段总结报告v1.0（23页珍藏版）》请在金锄头文库上搜索。

1、0 负载负载均衡性能均衡性能评评估估 第一第一阶阶段段总结报总结报告告 V 1.0 版版 总页数正文附录生效日期 编制：性能测试小组审批： 1 目目 录录 目目 录录1 第一章第一章 项目概述项目概述3 1.1 项目背景.3 1.2 项目目标.3 1.3 项目指标.3 第二章第二章 评估及优化环境评估及优化环境4 2.1 测试环境系统部署和网络拓扑图.4 2.2 测试工具.5 2.3 应用配置环境.5 第三章第三章 评估及优化策略评估及优化策略5 3.1 评估策略.5 3.2 测试环境的可参考性 .5 4 评估场景评估场景.6 4.1 用例选取原则 .6 4.2 场景设计策略 .6 4.2.1

2、并发策略6 4.2.2执行策略6 4.2.3停止执行策略6 4.3 场景设计 .7 4.3.1 场景一：国际正式制单.7 4.3.3 场景二：混合场景稳定性测试.8 第五章第五章 性能监控方案性能监控方案8 5.1 操作系统监控工具 .8 5.2 客户端的性能监控 .9 第六章第六章 负载压力性能测试结果负载压力性能测试结果9 2 6. 1 国际正式制单交易9 6.2 混合场景稳定性测试.16 6.2.1 关键交易响应时间.16 6.2.2系统资源性能指标分析17 第七章第七章 总结总结21 3 第一章第一章 项目概述项目概述 （涉及甲方业务信息，屏蔽） 1.2 项目目标项目目标 参考客户对项

3、目的总体需求，本次阶段性能测试的目标分为以下几点： 1) 验证负载均衡程序的原理和功能是否满足业务需要。 2) 评估负载均衡的程序在处理大并发业务下的转发能力的表现； 3)在发现性能问题情况时，配合项目组微软顾问找到系统中存在的性能瓶颈和质 量缺陷，协助项目组对系统性能进行调优。 1.3 项目指标项目指标 在本次性能评估和优化过程中制定以下的关键交易性能指标作为项目完成的标志： 序号关键交易响应时间要求 1制单3s 4.3 场景场景设计设计 4.3.1 场景一：场景一：国际正式制单国际正式制单 测试重点：测试重点： 1 大并发情况下国际正式制单响应时间； 2 评估不同并发条件下，响应时间和资源

4、消耗的趋势； 3 大并发进行制单时，系统资源 CPU、内存、IO 等使用情况； 4 大并发测试过程中拔掉网线，检查测试结果是否有用户退出； 5 大并发测试过程中，在 125 和 127 之间切换转发服务器； 6 单个用户制单，执行三次，计算转发代理程序的转发耗时的平均值； 7 代理转发程序的资源消耗。 场景描述：场景描述： 通过模拟多用户以 Smart Client 客户端方式登录系统，并发执行国际正式制单业务。 测试前准备工作：测试前准备工作： 1 测试需要的初始化数据； 2 规划测试参数。 操作过程及测试数据：操作过程及测试数据： 操作过程：登陆后选择：制单管理国际正式制单。 1 使用 L

5、oadRunner 模拟多个用户（10、20、30、40）进行并发国内正式制单； 2 执行三次并且记录每次的性能指标，最终结果取 3 次测试的平均值； 3 每次持续运行 5 分钟。 性能指标：性能指标： 1、 关键交易平均响应时间在 3 秒以内； 2、 Remoting Server 的关键性能指标； 8 4.3.3 场景二：混合场景场景二：混合场景稳定性测试稳定性测试 测试重点：测试重点： 1、 观察在混合场景中各用例的关键交易响应时间； 2、 评估 IIS 在处理大并发请求下的性能和稳定性； 3、 评估不同并发条件下，关键交易响应时间和资源消耗的趋势； 4、 评估 IIS 在处理大并发请求

6、下的性能和稳定性； 5、 代理转发程序的资源消耗。 场景描述：场景描述： 模拟国内正式制单、国际正式制单 2 个场景进行并发用户测试，持续时间 44 小时。 测试前准备工作：测试前准备工作： 基础数据量的准备； 性能指标：性能指标： 1、 关键交易平均响应时间在 3 秒以内； 2、 服务器的资源消耗 CPU、MEM、I/O、Net 3、 Remoting Server 的关键性能指标； 4、 数据库的锁，SGA 使用情况（IO，内存，CPU） 5、 在长时间运行情况下，记录可能出现的异常现象 第五章第五章 性能监控方案性能监控方案 5.1 操作系统监控工具操作系统监控工具 对于性能测试，获取哪

7、些性能指标与如何获取，直接决定了结果分析的质量，进 而决定了测试的质量。在主机系统方面，我们主要监控服务器 CPU 使用情况、服务器 内存使用情况、等方面的性能指标。 目前，对于主机系统进行性能监控的工具有很多，可以分成两类：一类是标准的 监控分析工具，即所有的 UNIX 都支持的监控分析工具；另一类是不同厂商的 UNIX 所特有的性能监控分析工具。由于本次测试主要是针对负载均衡程序的性能测试，在 9 此忽略数据库服务器的性能和测试参数，只要制单能成功保存到数据库即可。 5.2 客户端的性能监控客户端的性能监控 性能测试过程中需要监控测试用机的性能情况，如果 CPU 使用率达到 90%以上，

8、说明测试用机将成为性能测试的瓶颈，单台测试用机已经不能满足测试的需要，需要 增加测试用机。在测试过程中将不记录测试用机的性能情况，但需要观察测试用机的 性能，看是否能够满足测试的需要，测试过程中如果需要添加测试用机，要在测试报 告中加以说明。 第六章第六章 负载压力性能测试结果负载压力性能测试结果 6. 1 国际正式制单交易国际正式制单交易 6.1.1 系统吞吐量和响应时间系统吞吐量和响应时间 场景设计：通过 Loadrunner 分别模拟 10、20、30、40、50 并发用户，进行国际正 式制单，并迭代 10 次。 系统吞吐量如下图： 10 由上图我们可以看出，在测试开始阶段，随着并发用户

9、数的增加，系统的吞吐量也 在增加，但在 40、50 并发用户数的时候，系统的关键交易吞吐量趋于稳定，保存交易 的吞吐量为 33.77tps 左右。 关键交易响应时间曲线如下图： 通过上图可以看出，系统国际正式制单保存交易的响应时间，随着并发用户数的增 加而增加，在 50 并发用户的时候交易 90%响应时间达到 3.011s，不能满足客户的性能 需求。 6.1.2 CPU 资源消耗资源消耗 本节为并发 50 用户时的 Remoting Server 的 CPU 资源消耗曲线： Remoting Server CPU：*.*.*.125、*.*.*.127 11 通过上图可以看出此时 Remoti

10、ng Server125 的 CPU 稳定在 27%左右、Remoting Server127 的 CPU 稳定在 44%左右， 6.1.3 内存资源消耗内存资源消耗 本节为并发 50 用户时的 Remoting Server 和 Oracle 数据库的内存资源消耗曲线： Remoting Server MEM：202.106.139.27 上图为测试过程中 Remoting Server125 和 127 的内存消耗情况，通过图示可以看 出在执行制单后 Windows Server125 的内存消耗为 41M，Windows Server127 的内 存消耗为 27.5M，通过对后续测试过程

11、中对内存的观察，该部分内存可以回收。 12 6.1.4 拔掉网线后，拔掉网线后，CPU 资源走势图资源走势图 此场景是设计在国际制单场景中并发 20 个用户，当脚本正常运行至 5 分钟左右， 拔掉 Remoting Server127 的网线（视同 127 服务器掉线） 。 此图是在 127 服务器上建立的性能日志文件中 CPU 资源消耗记录。 从此图可以看出，当网线断掉之后，Remoting Server127 立即停止服务，LR 测 试工具接受 127 服务器的数据超时后，有 8 个用户退出，其他用户登陆 125 服务器继 续提交请求。被退出的用户主要是因为 127 服务器在接收到请求后，

12、还未来得及发送 返回数据时，拔掉了网线，由于超时，这些用户被系统退出。 由于 127 的网线被拔掉，LR 无法监测到 5 分钟后的 127 服务器的系统资源信息。 13 6.1.5 在在 125 和和 127 服务器之间转发切换服务器之间转发切换 6.1.5.16.1.5.1 CPUCPU 资源消耗图资源消耗图 此场景设计为 30 个用户并发国际制单,迭代 30 次。在向 125 和 127 同时发送请求 10 分钟后，控制代理程序停止向 127 转发请求，全部指向 125 服务器，再过 10 分钟后， 恢复向 127 发送请求，并停止向 125 发送请求。 从此图可以很明显看到，在 10 分

13、钟后，127 服务器的 CPU 明显降低接近 0，而 125 的 CPU 明显上升，由于 125 服务器的配置较好，双核 CPU，主频也较高，所以 CPU 上涨幅度不是很大。但是有上涨迹象；在 20 分钟后，127 服务器的 CPU 大幅上 涨，而 125 的 CPU 迅速降低接近 0，直至整个脚本运行结束。本次测试结果所有国际 制单全部执行完毕，没有用户退出。验证了代理程序的功能满足按照请求转发的要求。 6.1.5.26.1.5.2 内存资源消耗图内存资源消耗图 14 从此图可以看出，内存的资源消耗正常，125 服务器的内存消耗不超过 4M，127 服 务器的内存不超过 3M。脚本执行完毕后

14、，通过后续内存的走势图可以看到该部分内存 被回收。 6.1.6 1 个用户执行三遍，计算代理程序转发耗时个用户执行三遍，计算代理程序转发耗时 本次场景设计是在同一脚本执行中，分别通过代理和不通过代理两种场景下，每种 场景执行 3 次，取平均值对比，计算代理程序转发请求所消耗的时间。 走代理走代理不走代理不走代理转发时间转发时间 第一遍0.9030.7530.150 第二遍1.1310.9570.174 第三遍1.0580.8250.233 平均值平均值0.179 秒 从此表格可以看出，代理转发时间不超过 200 毫秒，在于微软的顾问讨论后，200 毫秒的延时是在合理范围之内的。 15 6.1.

15、76.1.7 代理转发程序资源损耗情况代理转发程序资源损耗情况 6.1.7.16.1.7.1 CPUCPU 资源消耗图资源消耗图 转发代理服务器 IP：192.168.36.100 在运行 50 个用户并发情况下，CPU 资源损耗图： 从此图可以看到，在响应时间不超过 3 秒的情况下，最大并发用户数为 50 个，代理转 发程序所消耗的 CPU 不超过 20%。 6.1.7.26.1.7.2 内存资源消耗图内存资源消耗图 从此图可以看出，内存消耗不大，不超过 20M，但是从内存消耗曲线图中看到，可用内 存一直在减少，没有出现回收迹象。需要在稳定性测试中注重内存回收问题。 16 6.2 混合场景稳

16、定性测试混合场景稳定性测试 场景设计：模拟国内正式制单、国际正式制单 2 个场景进行并发用户测试，持续时间 44 小时。 6.2.1 关键交易响应时间关键交易响应时间 44 小时稳定性测试后所完成的交易量：小时稳定性测试后所完成的交易量： 稳定性测试交易量结果 序号用例名称并发用户数预定交易量实际交易量 1 国内正式制单 20 52800 笔52800 笔 2 国际正式制单 20 52800 笔52800 笔 在进行 44 小时的稳定性测试后，国内正式制单、国际正式制单都能够完成预定的交易 量，分别完成了 52800 笔交易量。由于在执行 44 小时后，所有用户执行正常直至脚本 执行完毕，总共耗时 44 小时 20 分钟。 国内正式制单保存交易响应时间国内正式制单保存交易响应时间 国内正式制单保存交易响应时间：1.084 秒 国际正式制单保存交易响应时间国际正式制单保存交易响应时间 17 国际正式制单保存交易响应时间：国际正式制单保存交易响应时间：0.773 秒秒 TransactionTransaction NameNameMini