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

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

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

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

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

负载负载均衡性能均衡性能评评估估第一第一阶阶段段总结报总结报告告V1.0版版总页数正文附录生效日期编制性能测试小组审批目目录录目目录录1第一章第一章项目概述项目概述31.1项目背景.31.2项目目标.31.3项目指标.3第二章第二章评估及优化环境评估及优化环境42.1测试环境系统部署和网络拓扑图.42.2测试工具.52.3应用配置环境.5第三章第三章评估及优化策略评估及优化策略53.1评估策略.53.2测试环境的可参考性.54评估场景评估场景.64.1用例选取原则.64.2场景设计策略.64.2.1并发策略64.2.2执行策略64.2.3停止执行策略64.3场景设计.74.3.1场景一国际正式制单.74.3.3场景二混合场景稳定性测试.8第五章第五章性能监控方案性能监控方案85.1操作系统监控工具.85.2客户端的性能监控.9第六章第六章负载压力性能测试结果负载压力性能测试结果96.1国际正式制单交易96.2混合场景稳定性测试.166.2.1关键交易响应时间.166.2.2系统资源性能指标分析17第七章第七章总结总结21（涉及甲方业务信息，屏蔽）1.2项目目标项目目标参考客户对项目的总体需求，本次阶段性能测试的目标分为以下几点1验证负载均衡程序的原理和功能是否满足业务需要。

2评估负载均衡的程序在处理大并发业务下的转发能力的表现；3在发现性能问题情况时，配合项目组微软顾问找到系统中存在的性能瓶颈和质量缺陷，协助项目组对系统性能进行调优。

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

场景描述场景描述通过模拟多用户以SmartClient客户端方式登录系统，并发执行国际正式制单业务。

测试前准备工作测试前准备工作1．测试需要的初始化数据；2．规划测试参数。

操作过程及测试数据操作过程及测试数据操作过程登陆后选择制单管理国际正式制单。

1．使用LoadRunner模拟多个用户（10、20、30、40）进行并发国内正式制单；2．执行三次并且记录每次的性能指标，最终结果取3次测试的平均值；3．每次持续运行5分钟。

性能指标性能指标1、关键交易平均响应时间在3秒以内；2、RemotingServer的关键性能指标；4.3.3场景二混合场景场景二混合场景稳定性测试稳定性测试测试重点测试重点1、观察在混合场景中各用例的关键交易响应时间；2、评估IIS在处理大并发请求下的性能和稳定性；3、评估不同并发条件下，关键交易响应时间和资源消耗的趋势；4、评估IIS在处理大并发请求下的性能和稳定性；5、代理转发程序的资源消耗。

场景描述场景描述模拟国内正式制单、国际正式制单2个场景进行并发用户测试，持续时间44小时。

测试前准备工作测试前准备工作基础数据量的准备；性能指标性能指标1、关键交易平均响应时间在3秒以内；2、服务器的资源消耗CPU、MEM、I/O、Net3、RemotingServer的关键性能指标；4、数据库的锁，SGA使用情况（IO，内存，CPU）5、在长时间运行情况下，记录可能出现的异常现象5.1操作系统监控工具操作系统监控工具对于性能测试，获取哪些性能指标与如何获取，直接决定了结果分析的质量，进而决定了测试的质量。

在主机系统方面，我们主要监控服务器CPU使用情况、服务器内存使用情况、等方面的性能指标。

目前，对于主机系统进行性能监控的工具有很多，可以分成两类一类是标准的监控分析工具，即所有的UNIX都支持的监控分析工具；另一类是不同厂商的UNIX所特有的性能监控分析工具。

由于本次测试主要是针对负载均衡程序的性能测试，在此忽略数据库服务器的性能和测试参数，只要制单能成功保存到数据库即可。

5.2客户端的性能监控客户端的性能监控性能测试过程中需要监控测试用机的性能情况，如果CPU使用率达到90以上，说明测试用机将成为性能测试的瓶颈，单台测试用机已经不能满足测试的需要，需要增加测试用机。

在测试过程中将不记录测试用机的性能情况，但需要观察测试用机的性能，看是否能够满足测试的需要，测试过程中如果需要添加测试用机，要在测试报告中加以说明。

6.1国际正式制单交易国际正式制单交易6.1.1系统吞吐量和响应时间系统吞吐量和响应时间场景设计通过Loadrunner分别模拟10、20、30、40、50并发用户，进行国际正式制单，并迭代10次。

系统吞吐量如下图由上图我们可以看出，在测试开始阶段，随着并发用户数的增加，系统的吞吐量也在增加，但在40、50并发用户数的时候，系统的关键交易吞吐量趋于稳定，保存交易的吞吐量为33.77tps左右。

关键交易响应时间曲线如下图通过上图可以看出，系统国际正式制单保存交易的响应时间，随着并发用户数的增加而增加，在50并发用户的时候交易90响应时间达到3.011s，不能满足客户的性能需求。

6.1.2CPU资源消耗资源消耗本节为并发50用户时的RemotingServer的CPU资源消耗曲线RemotingServerCPU*.*.*.125、*.*.*.127通过上图可以看出此时RemotingServer－125的CPU稳定在27左右、RemotingServer－127的CPU稳定在44左右，6.1.3内存资源消耗内存资源消耗本节为并发50用户时的RemotingServer和Oracle数据库的内存资源消耗曲线RemotingServerMEM202.106.139.27上图为测试过程中RemotingServer－125和127的内存消耗情况，通过图示可以看出在执行制单后WindowsServer－125的内存消耗为41M，WindowsServer－127的内存消耗为27.5M，通过对后续测试过程中对内存的观察，该部分内存可以回收。

6.1.4拔掉网线后，拔掉网线后，CPU资源走势图资源走势图此场景是设计在国际制单场景中并发20个用户，当脚本正常运行至5分钟左右，拔掉RemotingServer－127的网线（视同127服务器掉线）。

此图是在127服务器上建立的性能日志文件中CPU资源消耗记录。

从此图可以看出，当网线断掉之后，RemotingServer－127立即停止服务，LR测试工具接受127服务器的数据超时后，有8个用户退出，其他用户登陆125服务器继续提交请求。

被退出的用户主要是因为127服务器在接收到请求后，还未来得及发送返回数据时，拔掉了网线，由于超时，这些用户被系统退出。

由于127的网线被拔掉，LR无法监测到5分钟后的127服务器的系统资源信息。

6.1.5在在125和和127服务器之间转发切换服务器之间转发切换6.1.5.16.1.5.1CPUCPU资源消耗图资源消耗图此场景设计为30个用户并发国际制单,迭代30次。

在向125和127同时发送请求10分钟后，控制代理程序停止向127转发请求，全部指向125服务器，再过10分钟后，恢复向127发送请求，并停止向125发送请求。

从此图可以很明显看到，在10分钟后，127服务器的CPU明显降低接近0，而125的CPU明显上升，由于125服务器的配置较好，双核CPU，主频也较高，所以CPU上涨幅度不是很大。

但是有上涨迹象；在20分钟后，127服务器的CPU大幅上涨，而125的CPU迅速降低接近0，直至整个脚本运行结束。

本次测试结果所有国际制单全部执行完毕，没有用户退出。

验证了代理程序的功能满足按照请求转发的要求。

6.1.5.26.1.5.2内存资源消耗图内存资源消耗图从此图可以看出，内存的资源消耗正常，125服务器的内存消耗不超过4M，127服务器的内存不超过3M。

脚本执行完毕后，通过后续内存的走势图可以看到该部分内存被回收。

6.1.61个用户执行三遍，计算代理程序转发耗时个用户执行三遍，计算代理程序转发耗时本次场景设计是在同一脚本执行中，分别通过代理和不通过代理两种场景下，每种场景执行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.1CPUCPU资源消耗图资源消耗图转发代理服务器IP192.168.36.100在运行50个用户并发情况下，CPU资源损耗图从此图可以看到，在响应时间不超过3秒的情况下，最大并发用户数为50个，代理转发程序所消耗的CPU不超过20。

6.1.7.26.1.7.2内存资源消耗图内存资源消耗图从此图可以看出，内存消耗不大，不超过20M，但是从内存消耗曲线图中看到，可用内存一直在减少，没有出现回收迹象。

需要在稳定性测试中注重内存回收问题。

6.2混合场景稳定性测试混合场景稳定性测试场景设计模拟国内正式制单、国际正式制单2个场景进行并发用户测试，持续时间44小时。

6.2.1关键交易响应时间关键交易响应时间44小时稳定性测试后所完成的交易量小时稳定性测试后所完成的交易量稳定性测试交易量结果序号用例名称并发用户数预定交易量实际交易量1国内正式制单2052800笔52800笔2国际正式制单2052800笔52800笔在进行44小时的稳定性测试后，国内正式制单、国际正式制单都能够完成预定的交易量，分别完成了52800笔交易量。

由于在执行44小时后，所有用户执行正常直至脚本执行完毕，总共耗时44小时20分钟。

国内正式制单保存交易响应时间国内正式制单保存交易响应时间国内正式制单保存交易响应时间1.084秒国际正式制单保存交易响应时间国际正式制单保存交易响应时间国际正式制单保存交易响应时间国际正式制单保存交易响应时间0.773秒秒TransactionTransactionNameNameMinimumMinimumAverageAverage9090PercentPercentMaximumMaximum国内正式制单保存0.6721.0841.49930.765国际正式制单保存0.4530.7731.22623.011从上面的表中，我们可以看到绝大部分交易的平均响应时间和90Percent响应时间两个重要指标都能够在1.5秒中内完成。

6.2.2系统资源性能指标分析系统资源性能指标分析6.2.2.1CPU资源消耗资源消耗本节为并发41用户时的RemotingServer和Oracle数据库的CPU资源消耗曲线RemotingServer－125、127CPU*.*.*.125、*.*.*.127上图为RemotingServer的CPU资源消耗可以看出CPU利用率稳定在30以下，CPU利用率不高，总体运行比较平稳。

6.2.2.2内存资源消耗内存资源消耗本节为并发30用户时的RemotingServer和Oracle数据库的内存资源消耗曲线RemotingServerMEM*.*.*.125、*.*.*.127上图为测试过程中RemotingServer的内存消耗情况，通过图示可以看出在稳定性测试的过程中WindowsServer125的内存消耗为20M左右，可用内存维持在573M左右。

WindowsServer127的内存消耗为10M左右，可用内存维持在600MG左右。

6.2.36.2.3代理转发程序资源损耗情况代理转发程序资源损耗情况6.2.3.16.2.3.1CPUCPU资源消耗图资源消耗图转发代理服务器IP192.168.36.100在运行40个用户，持续周期为44个小时的稳定性性测试过程中，CPU资源曲线图如下从此图可以看到，40个用户的混合场景的稳定性测试中，代理转发程序所消耗的CPU不超过15。

CPU资源消耗正常。

6.2.3.26.2.3.2内存资源消耗图内存资源消耗图从此图可以看出，192.168.36.100（代理转发服务器）内存消耗很大，可用内存数从1087M降到893M，44个小时消耗了194M内存，但是从内存消耗曲线图中看到，可用内存一直在减少，通过后续观察内存一直没有回收迹象，直到关闭转发代理程序后，内存才全部释放。

由此可推断转发代理程序存在内存泄露。

本阶段性能测试历时两周（5月16日6月2日），完成后了方案中2个场景多个用例的测试与评估，以下是对本次测试结果的总结。

11．交易响应时间．交易响应时间下表是对测试过程中涉及到的所有性能指标的响应时间测试结果总结，其中包括了对各个性能指标的响应时间要求和实际的测试结果对比1国际制单保存3s40并发2.379秒50并发3.011秒通过此表可以看到，在2台应用服务器的情况下，最大并发量不能超过50个用户。

22．．CPUCPU资源消耗资源消耗测试过程中的转发代理服务器RemotingServer的CPU资源消耗情况如下转发代理服务器*.*.*.100转发代理程序05310*.*.*.125国际正式制单088.02127应用服务器*.*.*.127国际正式制单01004433．内存资源消耗．内存资源消耗测试过程中2台应用服务器内存的在交易执行过程中会消耗一定量的内存，消耗量最大不超过41M。

但通过对后续测试过程中对内存的观察，该部分内存可以回收。

但转发代理服务器上内存存在泄露问题，通过44小时稳定性测试，该服务器内从有194M内存没有释放，并且在不转发任何请求的情况下，还有有少量的内存在继续消耗。

此问题已反映给微软的顾问。

44．．手工测试手工测试在本次测试中，还通过手工测试感受了请求转发的效果，测试方法如下当登陆的时候采用同时向125和127服务器发送请求的方式，当登陆完毕后，当开始输入国际正式制单的内容时，停止向127服务器转发请求，全部指向125服务器后30秒（信道等待延时10秒），这时点保存按钮，保存完毕后，又将请求转发全部指向127服务器，并停止向125服务器后30秒，这时修改部分制单内容，再次点保存按钮，提示保存成功。

此手工操作说明，在制单过程中，来回切换转发代理服务器对客户端与服务器发送请求和接收数据没有影响，个人感觉反应速度没有变化。

由于条件有限，无法进行多人同时手工制单操作，今后在条件允许的情况下，可以做这方面的测试，让其他人体验下请求转发的效果。

综上所述，东航货运系统的负载均衡性能测试过程中，暂且不考虑数据库服务器的性能指标，仅对转发代理服务器和RemotingServer服务器进行性能监控，通过对转发代理服务器和2台应用服务器性能指标的分析，转发代理的方案是可行的，首先在不占用过多系统资源的情况下，能缓解服务器压力，吞吐量和并发量都有所提高，同一并发量的交易响应时间也有所降低，转发代理程序在功能上满足按照请求转发的要求。

遗留问题遗留问题通过44个小时的稳定性测试，发现转发代理服务器（*.*.*.100）的可用内存以每小时4.39M的速度减少，此结果是不能接受的，该问题已反馈给微软的顾问，待他们解决后，再做一次稳定性测试检查内存泄露问题。