负载均衡性能评估第一阶段总结报告vWord下载.doc
《负载均衡性能评估第一阶段总结报告vWord下载.doc》由会员分享，可在线阅读，更多相关《负载均衡性能评估第一阶段总结报告vWord下载.doc（23页珍藏版）》请在冰点文库上搜索。
第五章性能监控方案 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。
脚本执行完毕后，通过后续内存的走势图可以看到该部分内存被回收。
6.1.61个用户执行三遍，计算代理程序转发耗时
本次场景设计是在同一脚本执行中，分别通过代理和不通过代理两种场景下，每种场景执行3次，取平均值对比，计算代理程序转发请求所消耗的时间。
走代理
不走代理
转发时间
第一遍
0.903
0.753
0.150
第二遍
1.131
0.957
0.174
第三遍
1.058
0.825
0.233
平均值
0.179秒
从此表格可以看出，代理转发时间不超过200毫秒，在于微软的顾问讨论后，200毫秒的延时是在合理范围之内的。
6.1.7代理转发程序资源损耗情况
6.1.7.1CPU资源消耗图
转发代理服务器IP：
192.168.36.100
在运行50个用户并发情况下，CPU资源损耗图：
从此图可以看到，在响应时间不超过3秒的情况下，最大并发用户数为50个，代理转发程序所消耗的CPU不超过20%。
6.1.7.2内存资源消耗图
从此图可以看出，内存消耗不大，不超过20M，但是从内存消耗曲线图中看到，可用内存一直在减少，没有出现回收迹象。
需要在稳定性测试中注重内存回收问题。
6.2混合场景稳定性测试
6.2.1关键交易响应时间
44小时稳定性测试后所完成的交易量：
稳定性测试交易量结果
用例名称
并发用户数
预定交易量
实际交易量
国内正式制单
20
52800笔
在进行44小时的稳定性测试后，国内正式制单、国际正式制单都能够完成预定的交易量，分别完成了52800笔交易量。
由于在执行44小时后，所有用户执行正常直至脚本执行完毕，总共耗时44小时20分钟。
国内正式制单保存交易响应时间
国内正式制单保存交易响应时间：
1.084秒
国际正式制单保存交易响应时间
国际正式制单保存交易响应时间：
0.773秒
TransactionName
Minimum
Average
90Percent
Maximum
国内正式制单保存
0.672
1.084
1.499
30.765
国际正式制单保存
0.453
0.773
1.226
23.011
从上面的表中，我们可以看到绝大部分交易的平均响应时间和90Percent响应时间两个重要指标都能够在1.5秒中内完成。
6.2.2系统资源性能指标分析
6.2.2.1CPU资源消耗
本节为并发41用户时的RemotingServer和Oracle数据库的CPU资源消耗曲线：
RemotingServer－125、127CPU：
上图为RemotingServer的CPU资源消耗可以看出CPU利用率稳定在30%以下，CPU利用率不高，总体运行比较平稳。
6.2.2.2内存资源消耗
本节为并发30用户时的RemotingServer和Oracle数据库的内存资源消耗曲线：
上图为测试过程中RemotingServer的内存消耗情况，通过图示可以看出在稳定性测试的过程中WindowsServer125的内存消耗为20M左右，可用内存维持在573M左右。
WindowsServer127的内存消耗为10M左右，可用内存维持在600MG左右。
6.2.3代理转发程序资源损耗情况
6.2.3.1CPU资源消耗图
在运行40个用户，持续周期为44个小时的稳定性性测试过程中，CPU资源曲线图如下：
从此图可以看到，40个用户的混合场景的稳定性测试中，代理转发程序所消耗的CPU不超过15%。
CPU资源消耗正常。
6.2.3.2内存资源消耗图
从此图可以看出，192.168.36.100（代理转发服务器）内存消耗很大，可用内存数从1087M降到893M，44个小时消耗了194M内存，但是从内存消耗曲线图中看到，可用内存一直在减少，通过后续观察内存一直没有回收迹象，直到关闭转发代理程序后，内存才全部释放。
由此可推断转发代理程序存在内存泄露。
第七章总结
本阶段性能测试历时两周（5月16日~6月2日），完成后了方案中2个场景多个用例的测试与评估，以下是对本次测试结果的总结。
1．交易响应时间
下表是对测试过程中涉及到的所有性能指标的响应时间测试结果总结，其中包括了对各个性能指标的响应时间要求和实际的测试结果对比：
测试结果响应时间90%
国际制单保存
40并发2.379秒
50并发3.011秒
通过此表可以看到，在2台应用服务器的情况下，最大并发量不能超过50个用户。
2．CPU资源消耗
测试过程中的转发代理服务器RemotingServer的CPU资源消耗情况如下：
交易名
最小占用率
最大占用率
转发代理服务器
*.*.*.100
转发代理程序
53
10%
应用服务器
88.021
27%
100
44%
3．内存资源消耗
测试过程中2台应用服务器内存的在交易执行过程中会消耗一定量的内存，消耗量最大不超过41M。
但通过对后续测试过程中对内存的观察，该部分内存可以回收。
但转发代理服务器上内存存在泄露问题，通过44小时稳定性测试，该服务器内从有194M内存没有释放，并且在不转发任何请求的情况下，还有有少量的内存在继续消耗。
此问题已反映给微软的顾问。
4．手工测试
在本次测试中，还通过手工测试感受了请求转发的效果，测试方法如下：
当登陆的时候采用同时向125和127服务器发送请求的方式，当登陆完毕后，当开始输入国际正式制单的内容时，停止向127服务器转发请求，全部指向125服务器后30秒（信道等待延时10秒），这时点保存按钮，保存完毕后，又将请求转发全部指向127服务器，并停止向125服务器后30秒，这时修改部分制单内容，再次点保存按钮，提示保存成功。
此手工操作说明，在制单过程中，来回切换转发代理服务器对客户端与服务器发送请求和接收数据没有影响，个人感觉反应速度没有变化。
由于条件有限，无法进行多人同时手工制单操作，今后在条件允许的情况下，可以做这方面的测试，让其他人体验下请求转发的效果。
综上所述，东航货运系统的负载均衡性能测试过程中，暂且不考虑数据库服务器的性能指标，仅对转发代理服务器和RemotingServer服务器进行性能监控，通过对转发代理服务器和2台应用服务器性能指标的分析，转发代理的方案是可行的，首先在不占用过多系统资源的情况下，能缓解服务器压力，吞吐量和并发量都有所提高，同一并发量的交易响应时间也有所降低，转发代理程序在功能上满足按照请求转发的要求。
遗留问题
通过44个小时的稳定性测试，发现转发代理服务器（*.*.*.100）的可用内存以每小时4.39M的速度减少，此结果是不能接受的，该问题已反馈给微软的顾问，待他们解决后，再做一次稳定性测试检查内存泄露问题。
升级会员 