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

1、负载均衡性能评估第一阶段总结报告vdoc负载均衡性能评估第一阶段总结报告v 负载负载均衡性能均衡性能评评估估 第一第一阶阶段段总结报总结报告告 V 1.0 版版 总页数正文附录生效日期 编制性能测试小组审批 目目 录录 目目 录录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

2、.1 用例选取原则 .6 4.2 场景设计策略 .6 4.2.1并发策略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 6. 1 国际正式制单交易9 6.2 混合场景稳定性测试.16 6.2.1 关键交易响应时间.16 6.2.2系统资源性能指标分析17 第七章第七章 总结总结21 （涉及甲方业务信息，屏蔽） 1.2 项目目标项

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

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

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

6、描述场景描述 模拟国内正式制单、国际正式制单 2 个场景进行并发用户测试，持续时间 44 小时。 测试前准备工作测试前准备工作 基础数据量的准备； 性能指标性能指标 1、 关键交易平均响应时间在 3 秒以内； 2、 服务器的资源消耗 CPU、MEM、I/O、Net 3、 Remoting Server 的关键性能指标； 4、 数据库的锁，SGA 使用情况（IO，内存，CPU） 5、 在长时间运行情况下，记录可能出现的异常现象 5.1 操作系统监控工具操作系统监控工具 对于性能测试，获取哪些性能指标与如何获取，直接决定了结果分析的质量，进 而决定了测试的质量。 在主机系统方面，我们主要监控服务器

7、 CPU 使用情况、服务器 内存使用情况、等方面的性能指标。 目前，对于主机系统进行性能监控的工具有很多，可以分成两类一类是标准的 监控分析工具，即所有的 UNIX 都支持的监控分析工具；另一类是不同厂商的 UNIX 所特有的性能监控分析工具。 由于本次测试主要是针对负载均衡程序的性能测试，在 此忽略数据库服务器的性能和测试参数，只要制单能成功保存到数据库即可。 5.2 客户端的性能监控客户端的性能监控 性能测试过程中需要监控测试用机的性能情况，如果 CPU 使用率达到 90以上， 说明测试用机将成为性能测试的瓶颈，单台测试用机已经不能满足测试的需要，需要 增加测试用机。 在测试过程中将不记录

8、测试用机的性能情况，但需要观察测试用机的 性能，看是否能够满足测试的需要，测试过程中如果需要添加测试用机，要在测试报 告中加以说明。 6. 1 国际正式制单交易国际正式制单交易 6.1.1 系统吞吐量和响应时间系统吞吐量和响应时间 场景设计通过 Loadrunner 分别模拟 10、20、30、40、50 并发用户，进行国际正 式制单，并迭代 10 次。 系统吞吐量如下图 由上图我们可以看出，在测试开始阶段，随着并发用户数的增加，系统的吞吐量也 在增加，但在 40、50 并发用户数的时候，系统的关键交易吞吐量趋于稳定，保存交易 的吞吐量为 33.77tps 左右。 关键交易响应时间曲线如下图

9、通过上图可以看出，系统国际正式制单保存交易的响应时间，随着并发用户数的增 加而增加，在 50 并发用户的时候交易 90响应时间达到 3.011s，不能满足客户的性能 需求。 6.1.2 CPU 资源消耗资源消耗 本节为并发 50 用户时的 Remoting Server 的 CPU 资源消耗曲线 Remoting Server CPU*.*.*.125、*.*.*.127 通过上图可以看出此时 Remoting Server125 的 CPU 稳定在 27左右、Remoting Server127 的 CPU 稳定在 44左右， 6.1.3 内存资源消耗内存资源消耗 本节为并发 50 用户时的

10、 Remoting Server 和 Oracle 数据库的内存资源消耗曲线 Remoting Server MEM202.106.139.27 上图为测试过程中 Remoting Server125 和 127 的内存消耗情况，通过图示可以看 出在执行制单后 Windows Server125 的内存消耗为 41M，Windows Server127 的内 存消耗为 27.5M，通过对后续测试过程中对内存的观察，该部分内存可以回收。 6.1.4 拔掉网线后，拔掉网线后，CPU 资源走势图资源走势图 此场景是设计在国际制单场景中并发 20 个用户，当脚本正常运行至 5 分钟左右， 拔掉 Rem

11、oting Server127 的网线（视同 127 服务器掉线） 。 此图是在 127 服务器上建立的性能日志文件中 CPU 资源消耗记录。 从此图可以看出，当网线断掉之后，Remoting Server127 立即停止服务，LR 测 试工具接受 127 服务器的数据超时后，有 8 个用户退出，其他用户登陆 125 服务器继 续提交请求。 被退出的用户主要是因为 127 服务器在接收到请求后，还未来得及发送 返回数据时，拔掉了网线，由于超时，这些用户被系统退出。 由于 127 的网线被拔掉，LR 无法监测到 5 分钟后的 127 服务器的系统资源信息。 6.1.5 在在 125 和和 127

12、 服务器之间转发切换服务器之间转发切换 6.1.5.16.1.5.1 CPUCPU 资源消耗图资源消耗图 此场景设计为 30 个用户并发国际制单,迭代 30 次。 在向 125 和 127 同时发送请求 10 分钟后，控制代理程序停止向 127 转发请求，全部指向 125 服务器，再过 10 分钟后， 恢复向 127 发送请求，并停止向 125 发送请求。 从此图可以很明显看到，在 10 分钟后，127 服务器的 CPU 明显降低接近 0，而 125 的 CPU 明显上升，由于 125 服务器的配置较好，双核 CPU，主频也较高，所以 CPU 上涨幅度不是很大。 但是有上涨迹象；在 20 分钟

13、后，127 服务器的 CPU 大幅上 涨，而 125 的 CPU 迅速降低接近 0，直至整个脚本运行结束。 本次测试结果所有国际 制单全部执行完毕，没有用户退出。 验证了代理程序的功能满足按照请求转发的要求。 6.1.5.26.1.5.2 内存资源消耗图内存资源消耗图 从此图可以看出，内存的资源消耗正常，125 服务器的内存消耗不超过 4M，127 服 务器的内存不超过 3M。 脚本执行完毕后，通过后续内存的走势图可以看到该部分内存 被回收。 6.1.6 1 个用户执行三遍，计算代理程序转发耗时个用户执行三遍，计算代理程序转发耗时 本次场景设计是在同一脚本执行中，分别通过代理和不通过代理两种场

14、景下，每种 场景执行 3 次，取平均值对比，计算代理程序转发请求所消耗的时间。 走代理走代理不走代理不走代理转发时间转发时间 第一遍0.9030.7530.150 第二遍1.1310.9570.174 第三遍1.0580.8250.233 平均值平均值0.179 秒 从此表格可以看出，代理转发时间不超过 200 毫秒，在于微软的顾问讨论后，200 毫秒的延时是在合理范围之内的。 6.1.76.1.7 代理转发程序资源损耗情况代理转发程序资源损耗情况 6.1.7.16.1.7.1 CPUCPU 资源消耗图资源消耗图 转发代理服务器 IP192.168.36.100 在运行 50 个用户并发情况下

15、，CPU 资源损耗图 从此图可以看到，在响应时间不超过 3 秒的情况下，最大并发用户数为 50 个，代理转 发程序所消耗的 CPU 不超过 20。 6.1.7.26.1.7.2 内存资源消耗图内存资源消耗图 从此图可以看出，内存消耗不大，不超过 20M，但是从内存消耗曲线图中看到，可用内 存一直在减少，没有出现回收迹象。 需要在稳定性测试中注重内存回收问题。 6.2 混合场景稳定性测试混合场景稳定性测试 场景设计模拟国内正式制单、国际正式制单 2 个场景进行并发用户测试，持续时间 44 小时。 6.2.1 关键交易响应时间关键交易响应时间 44 小时稳定性测试后所完成的交易量小时稳定性测试后所

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

17、正式制单保存交易响应时间0.773 秒秒 TransactionTransaction NameNameMinimumMinimumAverageAverage9090 PercentPercentMaximumMaximum 国内正式制单保存 0.672 1.0841.49930.765 国际正式制单保存 0.4530.7731.22623.011 从上面的表中，我们可以看到绝大部分交易的平均响应时间和 90 Percent 响应时间两个 重要指标都能够在 1.5 秒中内完成。 6.2.2 系统资源性能指标分析系统资源性能指标分析 6.2.2.1 CPU 资源消耗资源消耗 本节为并发 41

18、用户时的 Remoting Server 和 Oracle 数据库的 CPU 资源消耗曲线 Remoting Server125、127 CPU*.*.*.125、*.*.*.127 上图为 Remoting Server 的 CPU 资源消耗可以看出 CPU 利用率稳定在 30以下，CPU 利用率不高，总体运行比较平稳。 6.2.2.2 内存资源消耗内存资源消耗 本节为并发 30 用户时的 Remoting Server 和 Oracle 数据库的内存资源消耗曲线 Remoting Server MEM*.*.*.125、*.*.*.127 上图为测试过程中 Remoting Server

19、的内存消耗情况，通过图示可以看出在稳定性测试 的过程中 Windows Server 125 的内存消耗为 20M 左右，可用内存维持在 573M 左右。 Windows Server 127 的内存消耗为 10M 左右，可用内存维持在 600MG 左右。 6.2.36.2.3 代理转发程序资源损耗情况代理转发程序资源损耗情况 6.2.3.16.2.3.1 CPUCPU 资源消耗图资源消耗图 转发代理服务器 IP192.168.36.100 在运行 40 个用户，持续周期为 44 个小时的稳定性性测试过程中，CPU 资源曲线图如下 从此图可以看到，40 个用户的混合场景的稳定性测试中，代理转发

20、程序所消耗的 CPU 不超过 15。 CPU 资源消耗正常。 6.2.3.26.2.3.2 内存资源消耗图内存资源消耗图 从此图可以看出，192.168.36.100（代理转发服务器）内存消耗很大，可用内存数从 1087M 降到 893M，44 个小时消耗了 194M 内存，但是从内存消耗曲线图中看到，可用内 存一直在减少，通过后续观察内存一直没有回收迹象，直到关闭转发代理程序后，内 存才全部释放。 由此可推断转发代理程序存在内存泄露。 本阶段性能测试历时两周（5 月 16 日6 月 2 日），完成后了方案中 2 个场景多个 用例的测试与评估，以下是对本次测试结果的总结。 1 1交易响应时间交

21、易响应时间 下表是对测试过程中涉及到的所有性能指标的响应时间测试结果总结，其中包括了 对各个性能指标的响应时间要求和实际的测试结果对比 1 国际制单保存 3s 40 并发 2.379 秒 50 并发 3.011 秒 通过此表可以看到，在 2 台应用服务器的情况下，最大并发量不能超过 50 个用户。 2 2CPUCPU 资源消耗资源消耗 测试过程中的转发代理服务器 Remoting Server 的 CPU 资源消耗情况如下 转发代理服务器*.*.*.100转发代理程序 05310 *.*.*.125 国际正式制单 088.02127 应用服务器 *.*.*.127 国际正式制单 010044

22、3 3内存资源消耗内存资源消耗 测试过程中 2 台应用服务器内存的在交易执行过程中会消耗一定量的内存，消耗量 最大不超过 41M。 但通过对后续测试过程中对内存的观察，该部分内存可以回收。 但转发代理服务器上内存存在泄露问题，通过 44 小时稳定性测试，该服务器内从 有 194M 内存没有释放，并且在不转发任何请求的情况下，还有有少量的内存在继续 消耗。 此问题已反映给微软的顾问。 4 4手工测试手工测试 在本次测试中，还通过手工测试感受了请求转发的效果，测试方法如下 当登陆的时候采用同时向 125 和 127 服务器发送请求的方式，当登陆完毕后，当开 始输入国际正式制单的内容时，停止向 12

23、7 服务器转发请求，全部指向 125 服务器后 30 秒（信道等待延时 10 秒） ，这时点保存按钮，保存完毕后，又将请求转发全部指向 127 服务器，并停止向 125 服务器后 30 秒，这时修改部分制单内容，再次点保存按钮， 提示保存成功。 此手工操作说明，在制单过程中，来回切换转发代理服务器对客户端与服务器发送 请求和接收数据没有影响，个人感觉反应速度没有变化。 由于条件有限，无法进行多 人同时手工制单操作，今后在条件允许的情况下，可以做这方面的测试，让其他人体 验下请求转发的效果。 综上所述，东航货运系统的负载均衡性能测试过程中，暂且不考虑数据库服务器的 性能指标，仅对转发代理服务器和 Remoting Server 服务器进行性能监控，通过对转发 代理服务器和 2 台应用服务器性能指标的分析，转发代理的方案是可行的，首先在不 占用过多系统资源的情况下，能缓解服务器压力，吞吐量和并发量都有所提高，同一 并发量的交易响应时间也有所降低，转发代理程序在功能上满足按照请求转发的要求。 遗留问题遗留问题 通过 44 个小时的稳定性测试，发现转发代理服务器（*.*.*.100）的可用内存以每 小时 4.39M 的速度减少，此结果是不能接受的，该问题已反馈给微软的顾问，待他们 解决后，再做一次稳定性测试检查内存泄露问题。