负载均衡性能评估第一阶段总结报告vWord下载.doc
《负载均衡性能评估第一阶段总结报告vWord下载.doc》由会员分享，可在线阅读，更多相关《负载均衡性能评估第一阶段总结报告vWord下载.doc（23页珍藏版）》请在冰豆网上搜索。
3.2测试环境的可参考性 5
4评估场景 6
4.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
22
第一章项目概述
（涉及甲方业务信息，屏蔽）
1.2项目目标
参考客户对项目的总体需求，本次阶段性能测试的目标分为以下几点：
1）验证负载均衡程序的原理和功能是否满足业务需要。
2）评估负载均衡的程序在处理大并发业务下的转发能力的表现；
3）在发现性能问题情况时，配合项目组微软顾问找到系统中存在的性能瓶颈和质量缺陷，协助项目组对系统性能进行调优。
1.3项目指标
在本次性能评估和优化过程中制定以下的关键交易性能指标作为项目完成的标志：
序号
关键交易
响应时间要求
1
制单
<
3s
第二章评估及优化环境
2.1测试环境系统部署和网络拓扑图
类别
服务器
资源
IP
OS
数据库
兼容机
P42.6G1G
*.*.*.174
Solaris9
RemotingServer-125
HPPC
P43.2G双核，1G
*.*.*.125
Windows2003
RemotingServer-127
P42.8G，512M
*.*.*.127
WindowsXP
LR压力机
P42.8G，1.5G
*.*.*.118
软件
版本
实例名称
Oracle
10g
Orcle
RemotingServer
1.1
LoadRunner
8.1
2.2测试工具
在本次评估过程中主要采用以下的性能分析和测试工具：
工具类型
目标
工具名称
监控工具
Windows和RemotingServer
Windows2003/XPPerfmon
PLSQL
2
负载生成工具
模拟负载场景
Loadrunnerv8.1
2.3应用配置环境
1）应用版本20080113
2）Remoting应用配置信息
第三章评估及优化策略
3.1评估策略
采用“双Remoting+单DB”的环境作为被测平台，通过模拟10~50个并发访问的用户，评估系统在处理并发交易时的转发能力和系统响应时间，然后结合系统资源消耗和响应时间进行性能分析。
3.2测试环境的可参考性
本次评估所用的软、硬件环境与正式生产环境具有一定的差距，虽然使用的测试数据都来自生产环境的数据库导出。
但是，由于测试环境与生产环境毕竟存在一定差距，所以性能测试结果能够说明在测试环境下东航货运系统的性能表现和性能指标，对未来实际运行环境下的性能指标只有部分参考意义。
4评估场景
4.1用例选取原则
1、系统中的关键业务；
2、日常系统运行中，使用频率较高的业务；
4.2场景设计策略
测试场景主要分两种，一种是大并发场景：
用户同时并发，忽略Thinktime，让应用服务器处于高速运转状态；
另一种是稳定性测试场景：
用户按每2秒一个用户登陆，每个用户制单迭代的时间间隔为一分钟。
4.2.1并发策略
考虑到目前测试环境的硬件配置有限，我们将采取由低到高的并发策略，来验证系统的性能和硬件资源消耗之间的关系，同时定位整体系统的瓶颈，然后进行优化或完善测试环境。
4.2.2执行策略
由于本次测试中选择的用例具有一定的关联性，所以我们将顺序执行，并且保证前一个场景的数据能够为后续场景所使用。
如：
首先进行制单模块的性能测试，测试完成后要保证制单的数据能够为配载使用，在配载完成后的数据能够为航班关闭使用。
4.2.3停止执行策略
评估执行过程中，如果关键交易的性能指标低于下表的相应要求，则停止评估执行。
（双Remoting+单DB）
保存
>
3s
4.3场景设计
国际正式制单
测试重点：
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的关键性能指标；
混合场景稳定性测试
1、观察在混合场景中各用例的关键交易响应时间；
2、评估IIS在处理大并发请求下的性能和稳定性；
3、评估不同并发条件下，关键交易响应时间和资源消耗的趋势；
4、评估IIS在处理大并发请求下的性能和稳定性；
5、代理转发程序的资源消耗。
模拟国内正式制单、国际正式制单2个场景进行并发用户测试，持续时间44小时。
基础数据量的准备；
2、服务器的资源消耗CPU、MEM、I/O、Net
3、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数据库的内存资源消耗曲线：
RemotingServerMEM：
202.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.1CPU资源消耗图
此场景设计为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。
脚本执行完毕后，通过后续内存的
升级会员 