LoadRunner对ezFas消防监控软件性能测试的数据分析
 
2009-04-16 作者:郭娜 王晓东 来源:网络
 

[摘 要]:本文介绍了同方ezFas消防监控软件的主要性能数据,论述了各种性能指标在测试中的用途。

[关键词]: 场景 性能数据 性能分析

Abstract: The article introduces the main performance datas of TongFang ezFas software and the use of datas in testing.

Keywords: Scene ,Performance Data ,Performance Analysis

1 ezFas消防监控软件网页的基本概况

ezFAS消防监控软件是同方股份公司开发的一个功能强大的城市火灾远程监控管理平台,主要面向大型火灾监控管理中心如省市、大型厂矿企业、石油、各类区域和行业内部的消防管理部门,为主管部门提供实时报警、视频监听、故障检测、统计分析等功能。

该系统包括报警受理系统,用户服务系统,信息查询系统,火警信息终端四部分组成。报警受理系统主要为监控中心提供实时报警,用户管理,视频查看,人员考勤,报表生成等各大主要功能。下面就对这套主要的报警受理系统的性能数据进行分析。

2 测试环境

服务器:

CPU 型号:Inter(R) Core(TM)2 Duo T5450

主频:1.66GHZ

内存容量:1.00GB

操作系统:Microsoft Windows Server 2003 Enterprise Edition SP2

客户端:

CPU 型号:Intel Pentium III

主频:930MHZ

内存容量:640MB

操作系统:Microsoft Windows XP Professional SP2

网络环境:

在测试网络中有且仅有两台测试计算机,测试机之间通过1个Hub连接。

3 测试场景

用户进入登陆模块,总共登陆500个用户,每分钟登陆10个用户。用户点击“ASE管理”,用户在查询的区县里面选择“石河子市”然后点击查找。查找结束后点击“退出”按钮,退出系统。

4 性能数据分析

我们对500个用户的同时登陆进程,进行每5分钟增加10个用户的加压测试。此次测 试在250分钟后结束。

4.1 Transactions Sunmmary(事务综述)

用户事务分析是站在用户角度进行的基础性能分析。此次测试一共运行的事务数为9690145,成功 968750,失败250。

观察发现随着用户数量的不断增加,失败的事务开始出现,并且出现的频率逐步升高。

当程序运行到200个用户同时登陆时,失败事务开始出现。由此可以直接判断出当200个用户同步登陆时系统运行出现异常。此系统最大承受压力为200个用户同步登陆。

但考虑到此套系统主要用于省级市的监控,对于最大的省份,监控中心数量不会超过50个,所有监控中心的用户同时登陆数量也不会超过100个。此套系统最大承受压力为200,所以性能已经大大超过要求,并不需要花费时间和精力优化系统的运行稳定性。

4.2 Average Transaciton Response Time(事务平均响应时间)

事务平均响应时间显示的是测试场景运行期间的每一秒内事务执行所用的平均时间,通过它可以分析测试场景运行期间系统性能的走向。

如果随着测试时间的变化,系统处理事务的速度开始逐渐变慢就说明应用系统随着投产时间的变化整体性能将会有下降的趋势。

在这次250分钟的测试中,事务相应平均时间没有大幅度的变化,但这不能说明系统就是稳定的,250分钟的测试时间很短,所以我们针对这个结果单独进行了5天持续不断的测试,发现性能也没有变化。说明整体性能过关。

将它与Transactions per Second(每秒通过事务数/TPS)进行对比,来分析事务数目对执行时间的影响。如果当压力加大时,点击率/TPS曲线变化缓慢且有了平坦的趋势,则可能是服务器开始出现瓶颈。但是在这次测试中TPS曲线随着压力的加大曲线变化成正比增加,这此台测试服务器完全能满足要求。在工程施工中只要服务器配置达到此台服务器配置即可。

*Transactions per Second (每秒通过事务数/TPS):显示在场景运行的每一秒钟,每个事物通过、失败以及挺直的数量,是考察系统性能的一个重要参数。通过它可以确定系统在任何给定时刻的时间事务负载。

4.3 Transaction Response Time(Distribution)(事务相应时间分布)

“事务相应时间分布”显示在场景运行过程中,事务执行所用时间的分布,通过它可以了解测试过程中不同相应时间的事物数量。如果我们预先定义了相关事务可以接受的最小和最大事务响应时间,则可以使用此图确定服务器性能是否在可以接受的范围呢。

此次测试定义了登陆时间<3秒,查询时间<5秒,退出时间〈2秒。从图片上看出登陆和退出时间完全符合要求,但是查询时间随着用户的不断增多以密指数的比例变大,当用户超过200个同时查询时,反映时间已经达到10秒以上。不能满足系统需要。

经过对程序的分析发现,查询时需要调用的表过多,设计太过复杂。将表单的设计简单化即可解决问题。

以前表结构的设计:

现在将所有内容统一到一张表格中:

经过对程序的修改后再次进行测试,问题已经解决,所有用户同时查询时反映时间也在要求之下。

4.4 Hits per Second(每秒点击次数)

“每秒点击次数”是运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。同uota可以评估虚拟用户长生的负载量。

⑴下面我们将它和“平均事务响应时间”图比较,来查看点击次数对事务性能产生的影响。通过对查看“每秒点击次数”,可以判断系统是否稳定。

4.5 单用户系统登陆和查询报警信息资源特性表

以上是对于测试性能的一些最基本的数据分析,如果测试性能涉及到SQL Server,我在下列出比较关键的几个数据。

5 结论

测试结果表明,500个用户在并发登陆系统,查询ASE信息,退出系统的响应时间分别不超过2秒和5秒。服务器资源占用情况正常。系统在模拟测试环境中运行稳定,可以通过。


火龙果软件/UML软件工程组织致力于提高您的软件工程实践能力,我们不断地吸取业界的宝贵经验,向您提供经过数百家企业验证的有效的工程技术实践经验,同时关注最新的理论进展,帮助您“领跑您所在行业的软件世界”。
资源网站: UML软件工程组织