《负载均衡性能评估第一阶段总结报告v》由会员分享，可在线阅读，更多相关《负载均衡性能评估第一阶段总结报告v（23页珍藏版）》请在金锄头文库上搜索。
1、负载均衡性能评估第一阶段总结报告V 1.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场景设计策略6并发策略6执行策略6停止执行策略64.3场景设计74.3.1 场景一：国际正式制单74.3.3 场景二：混合场景稳定性测试8第五章 性能监控方案85.1操作系统监控工具85.2客户端的性能监控9第六章
2、负载压力性能测试结果96. 1 国际正式制单交易96.2 混合场景稳定性测试166.2.1 关键交易响应时间16系统资源性能指标分析17第七章 总结21第一章 项目概述（涉及甲方业务信息，屏蔽）1.2 项目目标参考客户对项目的总体需求，本次阶段性能测试的目标分为以下几点：1) 验证负载均衡程序的原理和功能是否满足业务需要。2) 评估负载均衡的程序在处理大并发业务下的转发能力的表现；3) 在发现性能问题情况时，配合项目组微软顾问找到系统中存在的性能瓶颈和质量缺陷，协助项目组对系统性能进行调优。1.3 项目指标在本次性能评估和优化过程中制定以下的关键交易性能指标作为项目完成的标志：序号关键交易响应
3、时间要求1制单3s4.3场景设计4.3.1 场景一：国际正式制单测试重点：1 大并发情况下国际正式制单响应时间；2 评估不同并发条件下，响应时间和资源消耗的趋势；3 大并发进行制单时，系统资源CPU、内存、IO等使用情况；4 大并发测试过程中拔掉网线，检查测试结果是否有用户退出；5 大并发测试过程中，在125和127之间切换转发服务器；6 单个用户制单，执行三次，计算转发代理程序的转发耗时的平均值；7 代理转发程序的资源消耗。场景描述：通过模拟多用户以Smart Client客户端方式登录系统，并发执行国际正式制单业务。测试前准备工作：1 测试需要的初始化数据；2 规划测试参数。操作过程及测试
4、数据：操作过程：登陆后选择：制单管理国际正式制单。1 使用LoadRunner模拟多个用户（10、20、30、40）进行并发国内正式制单；2 执行三次并且记录每次的性能指标，最终结果取3次测试的平均值；3 每次持续运行5分钟。性能指标： 1、 关键交易平均响应时间在3秒以内；2、 Remoting Server的关键性能指标；4.3.3 场景二：混合场景稳定性测试测试重点：1、 观察在混合场景中各用例的关键交易响应时间；2、 评估IIS在处理大并发请求下的性能和稳定性；3、 评估不同并发条件下，关键交易响应时间和资源消耗的趋势；4、 评估IIS在处理大并发请求下的性能和稳定性；5、 代理转发程
5、序的资源消耗。场景描述：模拟国内正式制单、国际正式制单2个场景进行并发用户测试，持续时间44小时。测试前准备工作：基础数据量的准备；性能指标： 1、 关键交易平均响应时间在3秒以内；2、 服务器的资源消耗CPU、MEM、I/O、Net3、 Remoting Server的关键性能指标； 4、 数据库的锁，SGA使用情况（IO，内存，CPU）5、 在长时间运行情况下，记录可能出现的异常现象第五章 性能监控方案5.1操作系统监控工具对于性能测试，获取哪些性能指标与如何获取，直接决定了结果分析的质量，进而决定了测试的质量。在主机系统方面，我们主要监控服务器CPU使用情况、服务器内存使用情况、等方面的
6、性能指标。目前，对于主机系统进行性能监控的工具有很多，可以分成两类：一类是标准的监控分析工具，即所有的UNIX都支持的监控分析工具；另一类是不同厂商的UNIX所特有的性能监控分析工具。由于本次测试主要是针对负载均衡程序的性能测试，在此忽略数据库服务器的性能和测试参数，只要制单能成功保存到数据库即可。5.2客户端的性能监控性能测试过程中需要监控测试用机的性能情况，如果CPU使用率达到90%以上，说明测试用机将成为性能测试的瓶颈，单台测试用机已经不能满足测试的需要，需要增加测试用机。在测试过程中将不记录测试用机的性能情况，但需要观察测试用机的性能，看是否能够满足测试的需要，测试过程中如果需要添加测
7、试用机，要在测试报告中加以说明。第六章 负载压力性能测试结果6. 1 国际正式制单交易6.1.1 系统吞吐量和响应时间场景设计：通过Loadrunner分别模拟10、20、30、40、50并发用户，进行国际正式制单，并迭代10次。系统吞吐量如下图：由上图我们可以看出，在测试开始阶段，随着并发用户数的增加，系统的吞吐量也在增加，但在40、50并发用户数的时候，系统的关键交易吞吐量趋于稳定，保存交易的吞吐量为33.77tps左右。关键交易响应时间曲线如下图：通过上图可以看出，系统国际正式制单保存交易的响应时间，随着并发用户数的增加而增加，在50并发用户的时候交易90%响应时间达到3.011s，不能
8、满足客户的性能需求。 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用户时的Remoting Server和Oracle数据库的内存资源消耗曲线：上图为测试过程中Remoting Server125和127的内存消耗情况，通过图示可以看出在执行制单后Windows Server125的
9、内存消耗为41M，Windows Server127的内存消耗为27.5M，通过对后续测试过程中对内存的观察，该部分内存可以回收。6.1.4 拔掉网线后，CPU资源走势图此场景是设计在国际制单场景中并发20个用户，当脚本正常运行至5分钟左右，拔掉Remoting Server127的网线（视同127服务器掉线）。此图是在127服务器上建立的性能日志文件中CPU资源消耗记录。从此图可以看出，当网线断掉之后，Remoting Server127立即停止服务，LR测试工具接受127服务器的数据超时后，有8个用户退出，其他用户登陆125服务器继续提交请求。被退出的用户主要是因为127服务器在接收到请求
10、后，还未来得及发送返回数据时，拔掉了网线，由于超时，这些用户被系统退出。由于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，主频也较高，所以CPU上涨幅度不是很大。但是有上涨迹象；在20分钟后，127服务器的CPU大幅上涨，而125的CPU迅速降低接近0，直至整个脚本运行结束。本次测试结果所有国际制单全部执行完毕，没有用户退出。验证了代理程序的功能满足按照请求转发的要求。6.1.5.2 内存资源消耗图从此图可以看出，内存的资源消耗正常，125服务器的内存消耗不超过4M，127服务器的内存不超过3M。脚本执行完毕后，通过后续内存的走势图可以看到该部分内存被回收。6.1.6 1个用户执行三遍，计算代理程序转发耗时本次场景设计是在同一脚本执行中，分别通过代理和不通过代理两
