压力测试在真实环境下进行的意义—财务信息管理系统压力测试

文｜曾建国

压力测试在真实环境下进行的意义—财务信息管理系统压力测试

文｜曾建国

应用系统压力测试，顾名思义就是测试系统能支持的最大负载。 成熟软件系统上线前是否还需要做压力测试，大家一直心存疑问。以我负责实施的财务信息系统为例，应用软件供应商根据客户端访问量结合以往的经验推荐了最佳方案，项目方案也经过专家一致评审通过。根据方案，项目方采购的软、硬件，服务器、操作系统、数据库、中间件、应用软件都是成熟产品，并且应用软件供应商已经基于各种平台做过压力测试，还有漂亮的压力测试报告。在这种情况下，究竟要不要花费大量的时间和精力在系统上线前做压力测试？我的回答是：需要。

项目系统结构示意图：

项目测试方案：压力测试在真实的环境中进行，服务器、操作系统、中间件集群环境、数据库集群环境都不变，克隆出一个结构完全相同的数据库，所有的业务节点均根据实际访问量上限上浮30%设置了访问并发访问数，测试数据以真实的业务为基础进行模拟，尽可能接近上线后的真实应用场景。

压力测试远远没有想象中的顺利，在这一过程中，我们发现了以下一些问题，通过对这些问题的解决优化了数据库集群性能。

一、应用服务器上有的线程长时间处于运行状态不能正常结束

最初我们都以为是应用软件的程序有bug，把问题反馈给系统开发人员，开发人员花费了大量的精力调试相关节点程序，始终没能解决问题。

最后压力测试小组人员通过检测工具发现应用服务器之间的代码不同步，两台从服务器（应用服务器2、3）与主服务器（应用服务器1）之间的代码不完全相同，原因可能是应用软件安装完成后打补丁导致了部分代码没有同步更新。找到了问题根源，解决方法自然简单，更新两台从服务器的代码，问题得以解决。

二、数据库集群中服务器没有均衡压力

在测试中发现两台服务器组成的Rac集群有一台会根据压力的增加导致CPU、内存、I/O等发生相应变化，另外一台服务器基本没有变化。系统集成工程师通过查数据库服务器的远程会话数发现数据库rac集群中只有一台数据库服务器会根据访问量的增加会话数出现增长，另外一台服务器的会话数未出现任何变化。系统集成工程师判断可能是JDBC连接字符串有问题，当时JDBC连接字符串：(DESCRIPTION=(ADDRESS_ LIST=(ADDRESS=(PROTOCOL=TCP) (HOST=192．168．1．3)(PORT=1521))(ADDRESS=(PROTOCOL=TCP) (HOST=192．168．1．4)(PORT=1521))) (L O A D_B A L A N C E=y e s) (FAILOVER=on) (CONNECT_ DATA=(SERVICE_NAME=test) (FAILOVER_MODE=(TYPE=SELECT) (METHOD=BASIC)(RETRIES=20) (DELAY=60))))

这可是一个经验丰富的应用软件供应商售后实施工程师配置出来的结果，关键是配置完成后软件系统测试成功通过，没有报任何错误。通过查阅官方资料，再仔细比对校验，发现有一个反括弧的位置提前终结在第二台服务器的端口号后，正确的位置应该是把“(PORT=1521)))”的最后一个反括弧 移到“(LOAD_ BALANCE=yes)(FAILOVER=on)”后，即：“(PORT=1521)) (LOAD_ BALANCE=yes)(FAILOVER=on))”更改后压力终于出现均很，再也不会忙闲不均。

三、做某些业务时数据库集群服务器CPU使用率居高不下

我们还发现，压力测试中执行某些业务时数据库服务器的CPU使用率上升很快，长时间使用率达到100%，这对数据库服务器是个巨大的考验。经过跟踪程序分析，发现问题出在SQL语句上，数据库表缺少相关索引，一旦发起较大的查询时，数据库由于缺少索引严重影响性能。为了确保将来使用时尽量不会发生类似情况，我们把所有的业务节点都进行了测试，根据测试情况为相应的表添加了索引。

四、发起较大的查询或报表计算时应用服务器集群有的节点出现崩溃

在测试时发现，一旦出现大查询或者较大量计算时，应用集群中有的节点会崩溃，经过测试即使并发数不大，也会出现有的节点被压崩溃的现象。通过工具监测发现IHS(IBM HTTP SERVER)在分配任务时，不是把任务平均分配到9个节点，而是会持续把任务分配给同一节点。几经测试，原来是压力测试工程师根据以往的经验为了能够得到漂亮的测试报告删除了IHS配置文件plugin-cfg．xml中各节点的CloneID，他们认为这样客户端能得到更快的响应。恢复了plugincfg．xml中各节点的CloneID，任务几乎可以得到平均分配，再也没有出现节点崩溃的现象。

五、数据库集群性能的不断优化

系统所用数据库是根据应用软件供应商的建议采购的Oracle数据库，安装由数据库供应商原厂工程师负责。安装前，就安装时的注意事项，参数配置等已经多次与应用软件的售后实施工程师沟通，完全按照他们的要求配置。应用软件的实施工程师上门安装时又对相关参数进行了校验。压力测试小组的工程师上门准备进行压力测试时前又对数据库的很多参数进行了优化，并且根据测试结果再次进行参数优化。经过多次反反复复的调整优化目的是确保数据库集群运行在相对最优的状态。

随着压力测试的推进，系统的种种问题也相继暴露无遗，大家一起集中排查问题，查找问题根源，再根据不同的问题给出相应的最佳处理问题的方案。我们解决了服务器代码不同步、JDBC连接字符串儿没有生效、数据库表中缺少关键索引、IHS配置文件个别参数配置不当的问题以及优化数据库集群性能。

压力测试可以检验系统究竟能承受多大的压力，发现系统的瓶颈所在，究竟是网络、内存、CPU还是I/O等，让我们做到对系统心中有数，不至于系统上线后一片茫然，待到出现问题再四处灭火，更重要的是能帮做你发现系统的配置是否合理，数据库集群、中间件集群、操作系统各参数是否调整到最佳。

软件应用系统在真实的环境中进行压力测试，最大的益处就是可以矫正实施人员人为因素导致的软件应用系统、中间件、数据库等各种参数配置不当。其实不仅仅是软件应用系统需要在真实地环境中进行压力测试，推而广之，其他的应用系统及各种应用也应该在真实地环境下进行，只有在真实的环境下进行压力测试才能暴露出在实验环境中未能显现的各种问题，当然才能最大限度事半功倍的解决问题。在真实的环境中进行压力测试的过程就是不断发现问题解决问题的过程，也是使实际应用得到最大优化的过程。

（作者单位：新华社计财局）