1 需要剖析
1.1 剖析压测对象
1）什么是ClickHouse 和Elasticsearch
ClickHouse 是一个真正的列式数据库管理系统（DBMS)。在 ClickHouse 中，数据始终是按列存储的，包含矢量（向量或列块）执行的过程。只有有可能，操作都是基于矢量进行分派的，而不是单个的值，这被称为«矢量化查问执行»，它有利于升高理论的数据处理开销。
Elasticsearch是一个开源的分布式、RESTful 格调的搜寻和数据分析引擎，它的底层是开源库Apache Lucene。 它能够被这样精确地形容：
一个分布式的实时文档存储，每个字段能够被索引与搜寻
一个分布式实时剖析搜索引擎
能胜任上百个服务节点的扩大，并反对 PB 级别的结构化或者非结构化数据
2）为什么要对他们进行压测
家喻户晓，ClickHouse在根本场景体现十分优良，性能优于ES，然而咱们理论的业务查问中有很多是简单的业务查问场景，甚至是大数量的查问，所以为了在双十一业务峰值来到前，确保大促流动峰值业务稳定性，针对ClickHouse 和Elasticsearch在咱们理论业务场景中是否领有优良的抗压能力，通过这次性能压测，探测系统中的性能瓶颈点，进行针对性优化，从而晋升零碎性能。
1.2 制订压测指标
为什么会抉择这个（queryOBBacklogData）接口呢？
1）从复杂度来看，接口（queryOBBacklogData）查问了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<OutboundBacklogRespBO> preCrossDockInfoCF = CompletableFuture.supplyAsync( () -> wmsObCrossDockMapper.preCrossDockInfo(wmsObCrossDockQueryBo), executor); // 汇合工作信息-待调配订单 WmsObAssignOrderQueryBo wmsObAssignOrderQueryBo = wmsObAssignOrderQueryBoBuilder(queryBO, commonStartTime, commonEndTime); log.info("queryOBBacklogDataCK-wmsObAssignOrderQueryBo: {}", JSON.toJSONString(wmsObAssignOrderQueryBo)); CompletableFuture<Integer> preAssignOrderQtyCF = CompletableFuture.supplyAsync( () -> wmsObAssignOrderMapper.preAssignOrderInfo(wmsObAssignOrderQueryBo), executor); // 拣货信息-待拣货件数&待拣货工作数 WmsPickTaskQueryBo wmsPickTaskQueryBo = wmsPickTaskQueryBoBuilder(queryBO, commonStartTime, commonEndTime); log.info("queryOBBacklogDataCK-wmsPickTaskQueryBo: {}", JSON.toJSONString(wmsPickTaskQueryBo)); CompletableFuture<OutboundBacklogRespBO> prePickingInfoCF = CompletableFuture.supplyAsync( () -> wmsPickTaskMapper.pickTaskInfo(wmsPickTaskQueryBo), executor); // 分播信息-待分播件数&待分播工作 WmsCheckTaskDetailQueryBo wmsCheckTaskDetailQueryBo = wmsCheckTaskDetailQueryBoBuilder(queryBO, commonStartTime, commonEndTime); log.info("queryOBBacklogDataCK-wmsCheckTaskDetailQueryBo: {}", JSON.toJSONString(wmsCheckTaskDetailQueryBo)); CompletableFuture<OutboundBacklogRespBO> preSowInfoCF = CompletableFuture.supplyAsync( () -> wmsCheckTaskDetailMapper.checkTaskDetailInfo(wmsCheckTaskDetailQueryBo), executor); // 发货信息-待发货件数 WmsOrderSkuQueryBo wmsOrderSkuQueryBo = wmsOrderSkuQueryBoBuilder(queryBO, commonStartTime, commonEndTime); log.info("queryOBBacklogDataCK-wmsOrderSkuQueryBo: {}", JSON.toJSONString(wmsOrderSkuQueryBo)); CompletableFuture<Integer> preDispatchCF = CompletableFuture.supplyAsync( () -> wmsOrderSkuMapper.preDispatchInfo(wmsOrderSkuQueryBo), executor); return processResult(preCrossDockInfoCF, preAssignOrderQtyCF, prePickingInfoCF, preSowInfoCF, preDispatchCF);}2）接口（queryOBBacklogData），总共查问了5个表，如下：
wms.wms_ob_cross_dockwms.wms_ob_assign_orderwms.wms_picking_task.wms.wms_check_task_detailwms.wms_order_sku3）查问的数据量，如下：
select (ifnull(sum(m.shouldBeCrossedDockQty), 0) - ifnull(sum(m.satisfiedCrossedDockQty), 0)) as preCrossStockSkuQty, count(m.docId) as preCrossStockTaskQtyfrom 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截图能够看出，查问待越库件数&待越库工作数，共读了720817行数据
select count(distinct m.orderNo) as preAssignedOrderQtyfrom wms.wms_ob_assign_order m finalprewherem.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 = 0and m.deliveryDestination = 2and m.stopProductionFlag = 0and m.deleted = 0and m.orderType = 10从下面SQL截图能够看出，查问汇合工作信息-待调配订单，共读了153118行数据
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 prePickingTaskQtyfrom wms.wms_picking_task m finalprewherem.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 = 0and m.deliveryDestination = 2and m.pickLocalDetailDeleted = 0and m.shipmentOrderDeleted = 0and m.orderType = 10and (m.operateStatus = 0 or m.operateStatus = 1)从下面SQL截图能够看出，查问拣货信息-待拣货件数&待拣货工作数，共读了2673536行数据
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 prePickingTaskQtyfrom wms.wms_picking_task m finalprewherem.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 = 0and m.deliveryDestination = 2and m.pickLocalDetailDeleted = 0and m.shipmentOrderDeleted = 0and m.orderType = 10and (m.operateStatus = 0 or m.operateStatus = 1)从下面SQL截图能够看出，查问分播信息-待分播件数&待分播工作，共读了1448149行数据
select ifnull(sum(m.unTrackQty), 0) as unTrackQtyfrom 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 采集工具筹备
监控工具
http://origin.jd.com/ ：监控JVM，办法级别监控（提供秒级反对）
http://console.jex.jd.com/ ：提供异样堆栈监控，火焰图监控、线程堆栈剖析
http://x.devops.jdcloud.com/ ：反对查看clickhouse/Elasticsearch数据库服务每个节点的cpu使用率
http://dashboard.fireeye.jdl.cn/ ：监测应用服务器cpu使用率、内存使用率
4 压测执行及后果剖析
4.1 编写压测脚本工具
Forcebot（http://forcebot.jd.com） 是专门为开发人员、测试人员提供的性能测试平台，通过编写脚本、配置监控、设置场景、启动工作、实时监控、日志定位、导出报告一系列操作流程来实现性能测试，灵便的脚本配置满足同步、异步、集合点等多种发压模式。
帮忙文档（http://doc.jd.com/forcebot/he...）
4.2 设计压测数据
4.2.1 后期压测中名词解释
DBCP：数据库连接池，是 apache 上的一个Java连接池我的项目。DBCP通过连接池事后同数据库建设一些连贯放在内存中(即连接池中)，应用程序须要建设数据库连贯时间接到从接池中申请一个连贯应用，用完后由连接池回收该连贯，从而达到连贯复用，缩小资源耗费的目标。
maxTotal：是连接池中总连贯的最大数量，默认值8
max_thread：clickhouse中底层配置，解决SQL申请时应用的最大线程数。默认值是clickhouse服务器的外围数量。
coordinating：协调节点数，次要作用于申请转发，申请响应解决等轻量级操作
数据节点：次要是存储索引数据的节点，次要对文档进行增删改查操作，聚合操作等。数据节点对cpu，内存，io要求较高， 在优化的时候须要监控数据节点的状态，当资源不够的时候，须要在集群中增加新的节点
4.2.2 压测数据
clickhouse数据服务：32C128G6节点2正本
应用服务器：4核8G2
maxTotal=16
注：每次压测前，肯定要察看每个数据节点的cpu使用率
注：从下面压测过程中，序号6-12能够看出，并发用户数在减少，但tps没有幅度变动，查看发现bigdata dbcp数据库链接池最大线程数未配置，默认最大线程数是8，并发用户数减少至8当前，clickhouse cpu稳固在40%~50%之间不再减少，应用服务器CPU稳固在25%左右。
之后咱们调整maxTotal=50，通过调整max_thread不同的值，数据库节点CPU使用率放弃在50%左右，来查看相应的监测数据指标：应用服务CPU使用率、TPS、TP99、并发用户数。
clickhouse数据节点，CPU使用率：
Elasticsearch数据服务：32C128G6节点2正本
应用服务器：4核8G2
Elasticsearch同样放弃数据库服务CPU使用率达到（50%左右），再监控数据指标tps、tp99
调整指标如下：coordinating协调节点数、 数据节点、poolSize
指标1：coordinating=2，数据节点=4，poolSize=400
注：在压测的过程中发现，coordinating节点的cpu使用率达到51.69%，负载平衡的作用受限，所以协调节点需扩容2个节点
指标2：coordinating=4，数据节点=5，poolSize=800
注：在压测的过程中，发现CPU使用率（数据库）ES数据节点在40%左右的时候，始终上不去，查看日志发现activeCount曾经达到797，须要减少poolSize值
指标3：coordinating=4，数据节点=5，poolSize=1200
注：压测过程中，发现coordinating协调节点还是须要扩容，不能反对当初数据节点cpu使用率达到50%
Elasticsearch数据节点及协调节点，CPU使用率：
咱们在压测的过程中发现一些之前在开发过程中没发现的问题，首先bdcp数bigdata应用服务器，应用的线程池最大线程数为8时，成为瓶颈，用户数减少至8当前， clickhouse的cpu稳固在40%~50%之间不在减少，应用服务器CPU稳固在25%左右，其次warehouse集群协调节点配置低，协调节点CPU使用率高，最初是clickhouse-jdbc JavaCC解析sql效率低。
4.3 后果剖析
4.3.1 测试论断
1）clickhouse对并发有肯定的反对，并不是不反对高并发，能够通过调整max_thread进步并发
max_thread=32时，反对最大TPS 是37，相应TP99是122
max_thread=2时，反对最大TPS 是66，相应TP99是155
max_thread=1时，反对最大TPS 是86，相应TP99是206
2）在并发方面Elasticsearch比clickhouse反对的更好，然而相应的响应速度慢很多
Elasticsearch：对应的TPS是192，TP99是3050
clickhouse：对应的TPS 是86，TP99是206
综合考量，咱们认为clickhouse足以撑持咱们的业务诉求
4.3.2 优化倡议
对ES协调节点进行扩容
bigdata利用线程池最大线程数调高至200
bigdata利用 dbcp线程池maxTotal设置成50
读取配置文件工具类减少内存缓存
作者：潘雪艳