性能测试报告范例+

性能测试报告

版本<1.0>

1.概述

1.1.背景

Customer子系统是PSS系统内部存储旅客数据的唯一数据源；向全渠道，所有接触点提供高效旅客档案管理,旅客价值计算服务，支持航空公司基于旅客价值提供差异化、个性化旅客服务；Customer子系统是航空公司专属系统。

本次对CA集群进行性能测试和高可用性测试。

1.2.测试目的

1、验证Customer集群所能支持的最大性能容量

2、验证Customer集群的运行稳定性

3、验证Customer集群的高可用性和traveldata数据库解决方案的高可用性

2.测试准备

2.1.系统架构

图 1 逻辑架构图

图2 物理架构图

2.2.软硬件环境

2.2.1.硬件及底层软件配置

表 2 硬件及底层软件配置表2.2.2.应用及中间件配置

表3 应用及中间件配置表

2.3.测试脚本准备

表 4 脚本描述表2.4.时间人员安排

表5 时间人员安排表

3.测试执行

3.1.容量测试

3.1.1.场景1：Customer容量测试

a)案例描述

表6 场景描述

b)结果描述

图2 总事务TPS随vu变化曲线图

图3 响应时间随vu变化曲线图

图4 integration服务器CPU变化曲线图（10.6.154.172）

图5 server应用服务器CPU变化曲线图（10.6.154.175）

图6 数据库服务器CPU变化曲线图（10.6.184.208）

表7 性能指标统计及资源使用情况

场景1开始后，Customer事务TPS随vu数增加而同步增加。场景运行至6分04秒时，共启动了85个vu，TPS增加至2550个/秒，平均响应时间增加至45毫秒。此时3台integration 服务器的CPU利用率平均值14.9%，3台server服务器的CPU利用率平均值为22.6%，数据库主节点的CPU利用率为18.7%。此后再增加vu，TPS不再有明显增长，响应时间继续增加，可以判断6分04秒左右时，系统呈现性能拐点态势。达到拐点之后，系统性能基本稳定。

3.2.疲劳测试

3.2.1.场景2：Customer疲劳测试

a)案例描述

表8 场景描述

b)结果描述

图7 总事务TPS变化曲线图

图8 响应时间变化曲线图（10.6.50.81）

图9 integration服务器CPU变化曲线图（10.6.154.172）

图10 server服务器CPU变化曲线图（10.6.154.175）

图11 数据库服务器CPU变化曲线图（10.6.184.208）

表9 性能指标统计及资源使用情况

共启动了30个vu，向MQ队列发送Customer查询请求，TPS平均值为1197，平均响应时间为24毫秒。整个场景执行过程中，应用服务器的内存使用方面：free+buffer+cached 总量基本保持不变，swap交换区始终未被使用。Integration三台节点的CPU利用率平均值为7.3%，server三台节点的CPU利用率平均值为11.5%，数据库主节点的CPU利用率为8.9%.超时交易占总交易的比例为0.02%。

3.3.高可用性测试

3.3.1.场景3：integration高可用测试

表10 integration高可用性测试

3.3.2.场景4：Server高可用性测试

表11 server高可用性测试3.3.3.场景5：traveldata高可用性测试

表12 高可用性测试业务分析表

4.测试结果分析

4.1.容量测试

在当前测试环境下，对系统发送customer查询请求，系统支持的最大TPS数为2550个/秒，响应时间为45毫秒。此时3台integration服务器的CPU利用率平均值14.9%，3台server 服务器的CPU利用率平均值为22.6%，数据库主节点的CPU利用率为18.7%。此后再增加vu，TPS不再有明显增长，响应时间持续增加，可以判断6分04秒左右时，系统呈现性能拐点态势。达到拐点之后，系统性能基本稳定。由于本地网络流量已经达到了15MB/s，基本达到了压力机最大带宽，可能是导致TPS无法进一步增加的性能瓶颈。

4.2.疲劳测试

在当前测试环境下，系统可以在Customer查询请求的TPS为1200个/秒的压力下较平

稳地运行12个小时，事务平均响应时间为24毫秒。Integration三台节点的CPU利用率平均值为7.3%，server三台节点的CPU利用率平均值为11.5%，数据库主节点的CPU利用率为8.9%.应用服务器的内存使用方面，free+buffer+cached总量基本保持不变，swap交换区始终未被使用。超时交易占总交易的比例为0.02%。

4.3.高可用性测试

1、Integration高可用性测试：当发生integration核心应用进程丢失，服务器重启和单网卡故障时，Customer查询业务的TPS和响应时间基本不受影响，Customer服务持续可用。

2、Server高可用性测试：当发生server核心应用进程丢失和单网卡故障时，Customer 查询业务的TPS和响应时间基本不受影响，Customer服务持续可用；当发生服务器重启故障时，TPS下降至0，整个集群服务不可用，持续时间约为40秒。40秒后，系统会将发生节点故障的server进行隔离，TPS和响应时间恢复至故障前水平。在重启jboss服务时，jboss 尚未完全启动成功即开始接收请求，造成not ffp的报错，jboss成功启动后不再有not ffp的报错。当发生主节点server故障之后又发生integration单节点故障时，当1台server出现故障后，整个集群仍然可以访问，此时如果再出现任意1台integration不可用，那么对这台integration重启jboss之后，则该integration无法将请求发送至另外2台服务正常的server 上去。

3、Traveldata高可用性测试：当发生数据库主节点的集群软件异常、硬件宕机、服务器hang死、应用网故障、数据网故障、杀死数据库主进程、杀死数据库子进程故障时，数据库主节点会切换至数据库备1节点，造成一段时间内TPS下降至0，服务不可用，切换完成后TPS和响应时间恢复正常。Customer查询的不可访问时间为集群软件异常45秒、硬件宕机45秒、服务器hang死54秒、应用网故障50秒、数据网故障12秒、杀死数据库主进程45秒、杀死数据库子进程故障30秒。当发生数据库主节点应用网单网卡故障、数据网单网卡故障，数据库备节点的集群软件异常、硬件宕机、服务器hang死、应用网故障、数据网故障、杀死数据库主进程、杀死数据库子进程故障，数据库三节点脑裂故障时，Customer 查询的TPS和响应时间不会受到影响，应用服务始终可用。

5.主要问题

1、当发生server服务器故障时（通过init 6指令使该应用节点故障），TPS下降至0，整个集群服务不可用，持续时间约为40秒。40秒后，系统会将发生节点故障的server进行隔离，TPS和响应时间恢复至故障前水平，与预期结果不一致，存在一个2级缺陷；

2、当发生主节点server和integration双点故障时（先使主节点175失效，再使任意一

台integration失效），对这台integration重启jboss之后，该integration无法将请求发送至另外2台服务正常的server上去，原因是当前integration的配置文件中只和175一个server 节点连接，与预期结果不一致，存在一个2级缺陷。

6.风险分析及建议

1、当server节点重启jboss时，由于jboss尚未完全启动完毕即开始接收请求，造成not ffp的报错，jboss成功启动后不再有not ffp的报错发生，请研发和运行同事注意此风险的影响；

2、在Customer查询请求压力存在的情况下，对数据库审计功能打开写日志和读日志功能时，会造成TPS下降至0（服务不可用），持续约10秒钟，10秒钟后恢复正常，请运行同事注意此风险；

3、一旦应用服务器或数据库服务器的磁盘空间被占满后，Customer请求的响应时间会增加至150毫秒，建议加强对日志使用磁盘空间的监控；

4、建议尽快修改代码并提交回归测试。