负载均衡性能评估第一阶段总结报告vWord下载.doc

1、第五章 性能监控方案85.1操作系统监控工具85.2客户端的性能监控9第六章 负载压力性能测试结果96. 1 国际正式制单交易96.2 混合场景稳定性测试166.2.1 关键交易响应时间166.2.2系统资源性能指标分析17第七章 总结2122第一章 项目概述（涉及甲方业务信息，屏蔽）1.2 项目目标参考客户对项目的总体需求，本次阶段性能测试的目标分为以下几点：1） 验证负载均衡程序的原理和功能是否满足业务需要。2） 评估负载均衡的程序在处理大并发业务下的转发能力的表现；3） 在发现性能问题情况时，配合项目组微软顾问找到系统中存在的性能瓶颈和质量缺陷，协助项目组对系统性能进行调优。1.3 项目

2、指标在本次性能评估和优化过程中制定以下的关键交易性能指标作为项目完成的标志：序号关键交易响应时间要求1制单3s4.3场景设计国际正式制单测试重点：1 大并发情况下国际正式制单响应时间；2 评估不同并发条件下，响应时间和资源消耗的趋势；3 大并发进行制单时，系统资源CPU、内存、IO等使用情况；4 大并发测试过程中拔掉网线，检查测试结果是否有用户退出；5 大并发测试过程中，在125和127之间切换转发服务器；6 单个用户制单，执行三次，计算转发代理程序的转发耗时的平均值；7 代理转发程序的资源消耗。场景描述：通过模拟多用户以Smart Client客户端方式登录系统，并发执行国际正式制单业务。测

3、试前准备工作：1 测试需要的初始化数据；2 规划测试参数。操作过程及测试数据：操作过程：登陆后选择：制单管理国际正式制单。1 使用LoadRunner模拟多个用户（10、20、30、40）进行并发国内正式制单；2 执行三次并且记录每次的性能指标，最终结果取3次测试的平均值；3 每次持续运行5分钟。性能指标： 1、 关键交易平均响应时间在3秒以内；2、 Remoting Server的关键性能指标；混合场景稳定性测试1、 观察在混合场景中各用例的关键交易响应时间；2、 评估IIS在处理大并发请求下的性能和稳定性；3、 评估不同并发条件下，关键交易响应时间和资源消耗的趋势；4、 评估IIS在处理大

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

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

6、章 负载压力性能测试结果6. 1 国际正式制单交易6.1.1 系统吞吐量和响应时间场景设计：通过Loadrunner分别模拟10、20、30、40、50并发用户，进行国际正式制单，并迭代10次。系统吞吐量如下图：由上图我们可以看出，在测试开始阶段，随着并发用户数的增加，系统的吞吐量也在增加，但在40、50并发用户数的时候，系统的关键交易吞吐量趋于稳定，保存交易的吞吐量为33.77tps左右。关键交易响应时间曲线如下图：通过上图可以看出，系统国际正式制单保存交易的响应时间，随着并发用户数的增加而增加，在50并发用户的时候交易90%响应时间达到3.011s，不能满足客户的性能需求。6.1.2 CP

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

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

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

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

11、理程序转发请求所消耗的时间。走代理不走代理转发时间第一遍0.9030.7530.150第二遍1.1310.9570.174第三遍1.0580.8250.233平均值0.179秒从此表格可以看出，代理转发时间不超过200毫秒，在于微软的顾问讨论后，200毫秒的延时是在合理范围之内的。6.1.7 代理转发程序资源损耗情况6.1.7.1 CPU资源消耗图转发代理服务器IP：192.168.36.100在运行50个用户并发情况下，CPU资源损耗图：从此图可以看到，在响应时间不超过3秒的情况下，最大并发用户数为50个，代理转发程序所消耗的CPU不超过20%。6.1.7.2 内存资源消耗图从此图可以看出，

12、内存消耗不大，不超过20M，但是从内存消耗曲线图中看到，可用内存一直在减少，没有出现回收迹象。需要在稳定性测试中注重内存回收问题。6.2 混合场景稳定性测试6.2.1 关键交易响应时间44小时稳定性测试后所完成的交易量：稳定性测试交易量结果用例名称并发用户数预定交易量实际交易量国内正式制单2052800笔在进行44小时的稳定性测试后，国内正式制单、国际正式制单都能够完成预定的交易量，分别完成了52800笔交易量。由于在执行44小时后，所有用户执行正常直至脚本执行完毕，总共耗时44小时20分钟。国内正式制单保存交易响应时间国内正式制单保存交易响应时间：1.084秒国际正式制单保存交易响应时间国际

13、正式制单保存交易响应时间：0.773秒Transaction NameMinimumAverage90 PercentMaximum国内正式制单保存0.672 1.0841.49930.765国际正式制单保存0.4530.7731.22623.011从上面的表中，我们可以看到绝大部分交易的平均响应时间和90 Percent响应时间两个重要指标都能够在1.5秒中内完成。6.2.2系统资源性能指标分析6.2.2.1 CPU资源消耗本节为并发41用户时的Remoting Server和Oracle数据库的CPU资源消耗曲线：Remoting Server125、127 CPU：上图为Remoting

14、 Server的CPU资源消耗可以看出CPU利用率稳定在30%以下，CPU利用率不高，总体运行比较平稳。6.2.2.2 内存资源消耗本节为并发30用户时的Remoting Server和Oracle数据库的内存资源消耗曲线：上图为测试过程中Remoting Server的内存消耗情况，通过图示可以看出在稳定性测试的过程中Windows Server 125的内存消耗为20M左右，可用内存维持在573M左右。Windows Server 127的内存消耗为10M左右，可用内存维持在600MG左右。6.2.3 代理转发程序资源损耗情况6.2.3.1 CPU资源消耗图在运行40个用户，持续周期为44

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

16、是对本次测试结果的总结。1交易响应时间下表是对测试过程中涉及到的所有性能指标的响应时间测试结果总结，其中包括了对各个性能指标的响应时间要求和实际的测试结果对比：测试结果响应时间90%国际制单保存 40并发2.379秒 50并发3.011秒通过此表可以看到，在2台应用服务器的情况下，最大并发量不能超过50个用户。2CPU资源消耗测试过程中的转发代理服务器Remoting Server的CPU资源消耗情况如下：交易名最小占用率最大占用率转发代理服务器*.*.*.100转发代理程序5310%应用服务器88.02127%10044%3内存资源消耗测试过程中2台应用服务器内存的在交易执行过程中会消耗一定

17、量的内存，消耗量最大不超过41M。但通过对后续测试过程中对内存的观察，该部分内存可以回收。但转发代理服务器上内存存在泄露问题，通过44小时稳定性测试，该服务器内从有194M内存没有释放，并且在不转发任何请求的情况下，还有有少量的内存在继续消耗。此问题已反映给微软的顾问。4 手工测试在本次测试中，还通过手工测试感受了请求转发的效果，测试方法如下：当登陆的时候采用同时向125和127服务器发送请求的方式，当登陆完毕后，当开始输入国际正式制单的内容时，停止向127服务器转发请求，全部指向125服务器后30秒（信道等待延时10秒），这时点保存按钮，保存完毕后，又将请求转发全部指向127服务器，并停止向

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