压力测试总结分析怎么写范文（需求分析1.1分析压测对象对象及分析）

1 需求分析 1.1 压力测试对象分析 1）什么是和

是一个真正的列式数据库管理系统（DBMS）。在 中，数据始终存储在列中，包括向量（向量或列块）执行。只要有可能，操作都是基于向量而不是单个值来调度的，这称为“向量化查询执行”，它有助于减少实际的数据处理开销。

是一个开源的分布式、风格搜索和数据分析引擎，其底层是一个开源库。可以这样准确地描述：

2) 为什么要对他们进行压力测试

众所周知，在基础场景下性能非常好，性能比ES要好，但是我们实际的业务查询很多都是复杂的业务查询场景，甚至是大量的查询，所以为了保证之前的双十一业务高峰来临，保障大促活动高峰业务稳定性，针对的是在我们的实际业务场景中是否具备优秀的抗压能力。通过本次性能压力测试，我们可以发现系统中的性能瓶颈，进行针对性的优化，提升系统性能。

1.2 制定压力测量目标

为什么选择 this() 接口？

1）复杂度上，()查询了5次，代码如下：

/** * 切ck-queryOBBacklogData * @param queryBO * @return */ public OutboundBacklogRespBO queryOBBacklogDataCKNew(OutboundBacklogQueryBO queryBO) { log.info(” queryOBBacklogDataCK入参：{}”, JSON.toJSONString(queryBO)); // 公共条件-卡最近十天时间 String commonStartTime = DateUtils.getTime(DateUtil.format(new Date(), DateUtil.FORMAT_DATE), DateUtils.ELEVEN_AM, 1, -10); String commonEndTime = DateUtils.getTime(DateUtil.format(new Date(), DateUtil.FORMAT_DATE), DateUtils.ELEVEN_AM, 1, 1); // 越库信息-待越库件数&待越库任务数 WmsObCrossDockQueryBo wmsObCrossDockQueryBo = wmsObCrossDockQueryBoBuilder(queryBO,commonStartTime, commonEndTime); log.info(“queryOBBacklogDataCK-wmsObCrossDockQueryBo: {}”, JSON.toJSONString(wmsObCrossDockQueryBo)); CompletableFuture preCrossDockInfoCF = CompletableFuture.supplyAsync( () -> wmsObCrossDockMapper.preCrossDockInfo(wmsObCrossDockQueryBo), executor); // 集合任务信息-待分配订单 WmsObAssignOrderQueryBo wmsObAssignOrderQueryBo = wmsObAssignOrderQueryBoBuilder(queryBO, commonStartTime, commonEndTime); log.info(“queryOBBacklogDataCK-wmsObAssignOrderQueryBo: {}”, JSON.toJSONString(wmsObAssignOrderQueryBo)); CompletableFuture preAssignOrderQtyCF = CompletableFuture.supplyAsync( () -> wmsObAssignOrderMapper.preAssignOrderInfo(wmsObAssignOrderQueryBo), executor); // 拣货信息-待拣货件数&待拣货任务数 WmsPickTaskQueryBo wmsPickTaskQueryBo = wmsPickTaskQueryBoBuilder(queryBO, commonStartTime, commonEndTime); log.info(“queryOBBacklogDataCK-wmsPickTaskQueryBo: {}”, JSON.toJSONString(wmsPickTaskQueryBo)); CompletableFuture prePickingInfoCF = CompletableFuture.supplyAsync( () -> wmsPickTaskMapper.pickTaskInfo(wmsPickTaskQueryBo), executor); // 分播信息-待分播件数&待分播任务 WmsCheckTaskDetailQueryBo wmsCheckTaskDetailQueryBo = wmsCheckTaskDetailQueryBoBuilder(queryBO, commonStartTime, commonEndTime); log.info(“queryOBBacklogDataCK-wmsCheckTaskDetailQueryBo: {}”, JSON.toJSONString(wmsCheckTaskDetailQueryBo)); CompletableFuture preSowInfoCF = CompletableFuture.supplyAsync( () -> wmsCheckTaskDetailMapper.checkTaskDetailInfo(wmsCheckTaskDetailQueryBo), executor); // 发货信息-待发货件数 WmsOrderSkuQueryBo wmsOrderSkuQueryBo = wmsOrderSkuQueryBoBuilder(queryBO, commonStartTime, commonEndTime); log.info(“queryOBBacklogDataCK-wmsOrderSkuQueryBo: {}”, JSON.toJSONString(wmsOrderSkuQueryBo)); CompletableFuture preDispatchCF = CompletableFuture.supplyAsync( () -> wmsOrderSkuMapper.preDispatchInfo(wmsOrderSkuQueryBo), executor); return processResult(preCrossDockInfoCF, preAssignOrderQtyCF, prePickingInfoCF, preSowInfoCF, preDispatchCF); }

2）()，一共查询了5张表，如下：

wms.wms_ob_cross_dock wms.wms_ob_assign_order wms.wms_picking_task. wms.wms_check_task_detail wms.wms_order_sku

3）要查询的数据量如下：

select (ifnull(sum(m.shouldBeCrossedDockQty), 0) – ifnull(sum(m.satisfiedCrossedDockQty), 0)) as preCrossStockSkuQty, count(m.docId) as preCrossStockTaskQty from wms.wms_ob_cross_dock m final prewhere m.createTime >= 2021-12-03 11:00:00 and m.createTime <= 2021-12-14 11:00:00 and m.warehouseNo = 279_1 and m.orderType = 10 and tenantCode = TC90230202 where m.deleted = 0 and m.deliveryDestination = 2 and m.shipmentOrderDeleted = 0 and m.status = 0

从上面的SQL截图可以看出服务器监测，查询挂起的跨接数量&挂起的跨接任务数量，读取一共行数据

select count(distinct m.orderNo) as preAssignedOrderQty from wms.wms_ob_assign_order m final prewhere m.createTime >= 2021-12-03 11:00:00 and m.createTime <= 2021-12-14 11:00:00 and m.warehouseNo = 361_0 and tenantCode = TC90230202 where m.taskassignStatus = 0 and m.deliveryDestination = 2 and m.stopProductionFlag = 0 and m.deleted = 0 and m.orderType = 10

从上面的SQL截图可以看出，查询采集任务信息-要分配的订单，读取行数据一共

select minus(toInt32(ifnull(sum(m.locateQty), toDecimal64(0, 4))), toInt32(ifnull(sum(m.pickedQty), toDecimal64(0, 4)))) as prePickingSkuQty, count(distinct m.taskNo) as prePickingTaskQty from wms.wms_picking_task m final prewhere m.shipmentOrderCreateTime >= 2021-12-03 11:00:00 and m.shipmentOrderCreateTime <= 2021-12-14 11:00:00 and m.warehouseNo = 286_1 and tenantCode = TC90230202 where m.pickingTaskDeleted = 0 and m.deliveryDestination = 2 and m.pickLocalDetailDeleted = 0 and m.shipmentOrderDeleted = 0 and m.orderType = 10 and (m.operateStatus = 0 or m.operateStatus = 1)

从上面的SQL截图可以看出，查询拣货信息-待拣货件数&待拣货任务数，一共读取了行数据

select minus(toInt32(ifnull(sum(m.locateQty), toDecimal64(0, 4))), toInt32(ifnull(sum(m.pickedQty), toDecimal64(0, 4)))) as prePickingSkuQty, count(distinct m.taskNo) as prePickingTaskQty from wms.wms_picking_task m final prewhere m.shipmentOrderCreateTime >= 2021-12-03 11:00:00 and m.shipmentOrderCreateTime <= 2021-12-14 11:00:00 and m.warehouseNo = 279_1 and tenantCode = TC90230202 where m.pickingTaskDeleted = 0 and m.deliveryDestination = 2 and m.pickLocalDetailDeleted = 0 and m.shipmentOrderDeleted = 0 and m.orderType = 10 and (m.operateStatus = 0 or m.operateStatus = 1)

从上面的SQL截图可以看出，查询分发信息-待分发的片数&待分发的任务，总共读取了行数据

select ifnull(sum(m.unTrackQty), 0) as unTrackQty from wms.wms_order_sku m final prewhere m.shipmentOrderCreateTime >= 2021-12-03 11:00:00 and m.shipmentOrderCreateTime <= 2021-12-14 11:00:00 and m.warehouseNo = 280_1 and m.orderType = 10 and m.deliveryDestination = 2 and tenantCode = TC90230202 where m.shipmentOrderDeleted <> 1 and m.ckDeliveryTaskDeleted <> 1 and m.ckDeliveryTaskDetailDeleted <> 1 and m.ckDeliveryTaskStatus in (1,0,2)

从上面的SQL截图可以看出，一共读取了99591行数据来查询发货信息-要发货的件数

2 测试环境准备

为了尽可能发挥性能压测的作用，性能压测环境要尽量和线上环境保持一致，所以我们使用和线上环境一样的环境。

3 采集工具 准备 监控工具：监控JVM、方法级监控（提供二级支持）：提供异常堆栈监控、火焰图监控、线程堆栈分析：支持查看/数据库服务各节点CPU使用情况：监控应用服务器cpu利用率、内存利用率 4 压力测试执行与结果分析 4.1 编写压力测试脚本工具

() 是专门为开发人员和测试人员提供的性能测试平台。它通过编写脚本、配置监控、设置场景、启动任务、实时监控、日志定位、导出报表等一系列操作流程完成性能测试。灵活的脚本配置 可满足同步、异步、会合等多种压力模式。

帮助文档（）

4.2 设计压测数据 4.2.1 上一次压测术语解释 4.2.2 压测数据

数据服务：节点 2 副本

应用服务器：4核8G2

=16

注意：每次压力测试前，一定要观察每个数据节点的CPU使用率

注：从上述压测过程中，从序号6-12可以看出，并发用户数在增加，但tps变化不大。发现没有配置dbcp数据库链接池的最大线程数。默认最大线程数为8，并发用户数增加到8后，CPU稳定在40%到50%之间不再增加，应用服务器CPU稳定在25%左右。

之后我们调整=50。通过调整不同的值，数据库节点的CPU使用率保持在50%左右，查看对应的监控数据指标：应用服务CPU使用率、TPS、TP99、并发用户数。

数据节点，CPU使用率：

数据服务：节点 2 副本

应用服务器：4核8G2

还要保持数据库服务CPU使用率最高（50%左右），然后监控数据指标tps，tp99

调整指标如下：协调节点数、数据节点数、

指标 1:=2, 数据节点=4,=400

注：压测时发现节点CPU使用率达到51.69%，负载均衡的作用有限，需要将协调节点扩容2个节点

指标 2:=4, 数据节点=5,=800

注：压测时发现ES数据节点的CPU使用率（数据库）在40%左右时，上不去。查看日志发现已经达到797，需要增加数值。

指标 3:=4, 数据节点=5,=1200

注：压测时发现节点仍需扩容，无法支持数据节点当前cpu使用率达到50%。

数据节点和协调器节点，CPU使用率：

在压力测试的过程中，我们发现了一些之前在开发过程中没有发现的问题。首先，当 bdcp 应用服务器的数量和使用的线程池中的最大线程数为 8 时，就会成为瓶颈。用户数增加到8个后，它的cpu在40%到50%之间没有增加，应用服务器的cpu稳定在25%左右。其次，集群协调节点配置低，协调节点CPU占用率高，最后-jdbc解析SQL效率低。

4.3 结果分析 4.3.1 测试结论

1）对并发有一定的支持，但不支持高并发，可以通过调整来提高并发

2）在并发方面比支持的要好，但是相应的响应速度要慢很多

综合考虑，我们认为足以支撑我们的业务需求

4.3.2 优化建议扩展ES 节点，将应用程序dbcp线程池的应用程序线程池最大线程数增加到50，读取配置文件，增加内存缓存。