StarRocks 3.3使用Jmeter压测并发查询效果特别差

[Hongkun]

【详述】使用Jmeter进行压测，观察Starrocks的并发查询结果，根据截图1，Starrocks确实是并发处理的。我的jmeter是在本地测试的，然后选取了12条真实业务的sql，sql访问的同一张表，查询结果的统计如图二所示。可以发现，并发查询结果特别不理想，基本上查询时延和并发数都接近正比了，这非常不合理。想请问下这就是SR的正常水平吗？
【背景】没做过额外的操作
【业务影响】
【是否存算分离】否
【StarRocks版本】3.3.0
【集群规模】例如：3fe（3 follower）+13be（fe与be不混部）
【机器信息】32核 * 128G

备注：

1. 这是pipeline的相关参数，我的be是32核
   
2. 至于查询队列我觉得现阶段应该不是关键因素，我是默认没开启的。
3. 我不确定我在本地测试而且还是所有的sql都是同一张表有什么影响

[jingdan]

测试并发的话，pipeline_dop=1，另外可以发个profile看下，你们sql耗时主要在哪部分

[Hongkun]

感谢老师的回答，不过我还有几个疑惑：

1. pipeline_dop在3.0之后不是自适应的吗？设置成1的目的是什么呢？
2. 因为sql有12个，一起发出来有点大，您能先告诉我sql耗时在哪里可能会出这种问题吗？然后我跟您的推测去验证下，调几条再发出来。您怀疑是scan数据吗？竞争同一张表的数据上锁了？
   @jingdan

[jingdan]

3.3应该是自适应了，目前看cpu被打满，应该是有比较多的聚合和排序的操作，可以拿其中一个这样的sql的profile看下

[Hongkun]

是有比较多的聚合和排序。但是对于线程1 ，线程2， 线程5 cpu资源还是空余的，但是平均查询时间也是几乎跟并发数成正比的。

[Hongkun]

sql确实都不太一样，我查看了下，10sql有order, 3个左右的聚合。

[jingdan]

随便先拿个profile看下呢

[Hongkun]

好的，我挑选了两个，一个是最耗时的sql，另一个是比较靠前的sql。内容比较大，我放到文件里面了。
query2_profile.txt (88.6 KB) query5_profile.txt (89.9 KB)

[Hongkun]

为了方便您排查，我再贴两张图，一个线程是5，一个线程是10。然后sql的序号跟发的文件的query-**是一一对应的。
线程5:

线程10:

[jingdan]

jmeter怎么测试的？5个线程随机选sql，还是每次拿一个sql压？

[Hongkun]

我查了一下jmeter的压测逻辑以及根据profile情况。应该是这样的。
比如5个线程压测，有12个测试的sql
那么这五个线程都会按照相同的顺序同时执行一遍这12个sql。
@jingdan