|
《RailASSURETM 铁路资产管理》系统协议测试
一、项目概述及背景： “RAILASSURETM铁路资产管理 Build 1.0.1” 是由香港XX公司设计开发的针对铁路行业资产管理的专业软件管理系统。该系统包括“设备管理”、“维修计划”、“工单管理”、“维修预算”、“分析和管理报表”五个部分。检测中心受其委托对该系统进行性能测试。主要目的是明确该系统在不同测试环境下的性能状况、性能趋势和性能拐点，给予优化建议。
二、测试内容、测试方法和测试结果：
测试内容：选择系统“用户登录”、“工单”、“工时表”和“计划工作台” 的4个单一业务和1个混合关键业务流程，分别在Linux+Jboss 4.2.0.GA和Hp-Unix+Websphere6.1.0.0两种测试环境下进行负载和压力测试。
Linux+Jboss 4.2.0.GA测试环境的测试方法及结果：
选择“用户登录”、“工单”、“工时表”和“计划工作台”单一业务分别模拟32个在线用户，起始用户从0开始，每18秒加载2个用户，加载到32用户数后，持续运行30分钟。在测试过程中，出现了以下两个方面性能问题：1、JVM堆内存呈线性持续增长，用户登录时后台出现了大量的初始化操作,并且有大量的内存在这个过程没有被释放, 导致运行时间较长；2、SQL语句出现重复解析问题，事务成功率仅为25.5%,大量事务都以WEB服务器响应时间超时而失败。
选择“用户登录”、“工单”、“工时表”和“计划工作台”进行混合业务测试，其中“用户登录”业务模拟56个在线用户，“工单” 业务模拟80个在线用户、“工时表” 业务模拟32个在线用户和“计划工作台” 业务模拟32个在线用户，起始用户从0开始，每9秒加载2个用户，加载到200用户，持续运行1小时。系统运行30分钟后，Web服务器宕机，说明190用户超出系统的承载能力。
Hp-Unix+Websphere6.1.0.0测试环境的测试方法及结果：
根据该系统在Linux+Jboss 4.2.0.GA测试环境下的性能表现，结合系统本身的特点，我们采取降低负载、调整迭代时间等方式，设计了以下测试场景：分别对“用户登录”、“工单”、“工时表”混合业务进行50用户并发，70用户并发，100用户并发的负载测试。
选择“用户登录”、“工单”、“工时表”进行混合业务测试，“用户登录”业务模拟16个在线用户，业务操作的迭代时间为120秒，“工单” 业务模拟22个在线用户，业务操作的迭代时间为300秒，“工时表” 业务模拟12个在线用户，业务操作的迭代时间为360秒。起始用户从0开始，每30秒加载10个用户，加载到50用户，持续运行30分钟。测试结果表明：“登录”事务成功率为100%，平均响应时间为4.392秒；“工单”事务成功率为99.9%，平均响应时间为11.293秒；“工时表”事务成功率为100%，平均响应时间为4.024秒。说明在50用户并发的情况下，服务器运行正常。
选择“用户登录”、“工单”、“工时表”进行混合业务测试，“用户登录”业务模拟23个在线用户，业务操作的迭代时间为120秒，“工单” 业务模拟30个在线用户，业务操作的迭代时间为300秒，“工时表” 业务模拟17个在线用户，业务操作的迭代时间为360秒。起始用户从0开始，每30秒加载10个用户，加载到70用户，持续运行30分钟。测试结果表明：“登录”事务成功率为96.2%，平均响应时间为101.773秒；“工单”事务成功率为98.2%，平均响应时间为72.953秒；“工时表”事务成功率为100%，平均响应时间为20.954秒。与50用户相比，70用户并发情况下，响应时间明显增长，超过了业内标准（6秒），我们认为虽然此时服务器没有宕机，但是已经到达了极限。
选择“用户登录”、“工单”、“工时表”进行混合业务测试，“用户登录”业务模拟32个在线用户，业务操作的迭代时间为120秒，“工单” 业务模拟44个在线用户，业务操作的迭代时间为300秒，“工时表” 业务模拟24个在线用户，业务操作的迭代时间为360秒。起始用户从0开始，每30秒加载10个用户，加载到100用户，持续运行30分钟。测试结果表明：用户数最大达到72，其余用户初始化失败，运行8分钟后，系统宕机。到宕机时，事务成功率仅为55.53%。
以上两种环境下，应用服务器和数据库服务器的CPU平均使用率始终处于1.7%至68.7%范围内，符合业界标准（不超过80%）。
测试结果表明：系统的最佳并发用户数为50，超过此用户数，系统性能开始退化，响应时间加长，事务成功率降低；最大并发用户数为70，超过此用户数后，系统性能快速下降，响应时间成倍增长，事务成功率迅速降低，直至发生宕机。
三、系统优化建议
针对以上系统表现，建议从以下方向进行系统调优：
1．由于JVM堆内存的快速增长至最大值导致JVM堆处于频繁的垃圾回收过程中，从而使应用服务器响应时间表现极差，甚至宕机，而且二次测试结果都是在测试过程中出现大量的“WARNING: firstResult/maxResults specified with collection fetch; applying in memory!”异常。
2．由于数据库共享池报大量的sql library cache miss rate 100%警告，说明数据库共享池分配的内存不能满足SQL语句解析的需要，导致数据库反应过慢。
3. 目前中间件数据源的连接池属性值设置为10，线程池设置为50，对于并发数为200的系统，这个设置值得商榷。
4. 系统中的一些WEB模块调用EJB的Remote接口（远程调用），如果可能，请尽量改为调用Local接口（本地调用），可以提高性能。
5. JSF引擎、AJAX4JSF中都有好几个地方存在synchronized，这些synchronized会造成大量等待。这些synchronized是否是必要的，如果可能的话，请尽量减少，因为synchronized会严重影响并发性能。
|
|
|
