K6压测,执行match语句,使用where子句导致「吞吐率」差异(必现)

1、相关配置信息

  • nebula 版本:nebula graph v2.5.1

  • 部署方式(分布式):

    • 201、202、203 部署Nebula Graph集群
    • 001 运行压测工具 K6
  • 服务器信息(4台机器一样的配置)

    • CPU:2(单CPU十四核) E5-2690 v4 @ 2.60GHz* /
    • 内存:256GB
    • 硬盘: 2*960GB SSD
    • 网卡:2*10000Mb/s

2、问题具体描述

  • K6压测工具,根据业务场景,分别执行如下两条语句,得到的结果是 使用 where语句性能差一些(在多个场景下已经复现),如下所示
match (src:PROPERTY{name:'{}'})-[:SYNONYM]->(dst:PROPERTY) return dst

match (src:PROPERTY)-[:SYNONYM]->(dst:PROPERTY) where src.name == '{}' return dst
  • 执行以上NGQL语句,发现一个问题,使用where语句时的latency快,但其response时间长,同时QPS也相对较小,请问下是否遇到类似情况,什么原因导致的 where语句性能上的差异?

3、K6相关输出信息

  • K6 工具输出内容 600s(不使用where)
INFO[0000] 2021/09/27 16:38:03 [INFO] finish init the pool
execution: local
script: output/1-synonym-name.js
output: -

scenarios: (100.00%) 1 scenario, 300 max VUs, 10m30s max duration (incl. graceful stop):
* default: 300 looping VUs for 10m0s (gracefulStop: 30s)

INFO[0602] 2021/09/27 16:48:04 [INFO] begin close the nebula pool

running (10m01.0s), 000/300 VUs, 36505499 complete and 0 interrupted iterations
default ✓ [======================================] 300 VUs 10m0s
INFO[0637] 2021/09/27 16:48:40 [INFO] begin init the nebula pool
INFO[0637] 2021/09/27 16:48:40 [INFO] connection pool is initialized successfully
INFO[0637] 2021/09/27 16:48:40 [INFO] finish init the pool

✓ IsSucceed

█ setup

█ teardown

checks...............: 100.00% ✓ 36505499 ✗ 0
data_received........: 0 B 0 B/s
data_sent............: 0 B 0 B/s
iteration_duration...: min=1.57ms avg=4.91ms med=4.21ms max=1s p(90)=7.86ms p(95)=9.57ms p(99)=13.77ms
iterations...........: 36505499 60738.993506/s
latency..............: min=1192 avg=3861.751766 med=3152 max=47965 p(90)=6632 p(95)=8221 p(99)=11943
responseTime.........: min=1350 avg=4688.071612 med=4033 max=72860 p(90)=7600 p(95)=9269 p(99)=13282
vus..................: 300 min=0 max=300
vus_max..............: 300 min=300 max=300
  • K6 工具输出内容 600s(使用where)
INFO[0000] 2021/09/27 18:25:20 [INFO] finish init the pool
execution: local
script: scripts/2-synonym-name-where.js
output: -

scenarios: (100.00%) 1 scenario, 300 max VUs, 10m30s max duration (incl. graceful stop):
* default: 300 looping VUs for 10m0s (gracefulStop: 30s)

INFO[0603] 2021/09/27 18:35:22 [INFO] begin close the nebula pool

running (10m02.2s), 000/300 VUs, 34431596 complete and 0 interrupted iterations
default ✓ [======================================] 300 VUs 10m0s
INFO[0636] 2021/09/27 18:35:55 [INFO] begin init the nebula pool
INFO[0636] 2021/09/27 18:35:55 [INFO] connection pool is initialized successfully
INFO[0636] 2021/09/27 18:35:55 [INFO] finish init the pool

✓ IsSucceed

█ setup

█ teardown

checks...............: 100.00% ✓ 34431596 ✗ 0
data_received........: 0 B 0 B/s
data_sent............: 0 B 0 B/s
iteration_duration...: min=1.65ms avg=5.21ms med=4.51ms max=2.14s p(90)=8.18ms p(95)=9.97ms p(99)=14.26ms
iterations...........: 34431596 57180.279734/s
latency..............: min=1255 avg=3793.779895 med=3027 max=48020 p(90)=6577 p(95)=8267 p(99)=12167
responseTime.........: min=1455 avg=5009.584435 med=4358 max=80948 p(90)=7952 p(95)=9725 p(99)=13880
vus..................: 300 min=0 max=300
vus_max..............: 300 min=300 max=300

几个问题,你可以查一下:

  1. PROPERTY 的数据量级,大概有多少个点。
  2. 有没有其他的 tag,其他 tag 有没有属性 name,会不会命中 where 的条件。
  3. 将 k6 的结果输出到 csv,比对一下两种情况的 rows,看看是否一样。
1 个赞

感谢回复:

1、关于网络传输的问题,已经做过如下消融实验:

  • 为了排除where子句较长导致的网络传输问题,「未使用where的查询语句」使用空格填充,如下语句2 和 语句3保持长度一致

测试结果:带where语句(长度一致)仍然是「latency 小,respoonse 大」,指定发送次数、指定发送时间,都是该结果

2、系统中,PROPERTY 的数据在几万左右,如下统计

3、当前图空间中,其他tag有name属性

4、K6的压测值输出到csv文件,进行其中name关键词的对比,排序后是一致的

  • 执行时,顺序不一致,所以是从导出的csv文件中读取,然后排序进行对比,对比结果:内容是一样的

不好意思,我上面的回答是错误的,当时看错了。
这两个执行计划,在 index 那里是一样的,只是带 where 的,会多了一个 filter。

我今天在测试环境上用 k6 测一下,看会不会出现你说的,latency 小,response 大的情况。

另外,看你上面数据,差异比较小,你也可以试试:

  1. 用更大的数据来测一下,远不止 2w 的数据。
  2. 执行压测前,执行一下 balance data,balance leader,让 leader 均匀分布。

好的,谢谢。

后面的两个测试建议我们这边也换数据进行测试。

Hi,更新下当前进展:

  • 如下所示,K6工具的执行脚本中,采用nebula三台服务器进行初始化连接池,会存在:latency小,response大的问题(即该讨论中 提出的问题)

    //initial nebula connect pool
    var pool = nebulaPool.init("xxx.201:9669,xxx.202:9669,xxx.203:9669", 2000)

  • 只采用一台服务器初始化连接池时,发现并不存在以上问题,测试结果都是latency小,response也小。

    var pool = nebulaPool.init("xxx.201:9669", 2000)

    (三台服务器都单独测试过,其中203网络延迟会大一些,如下图所示)

根据以上现象,是否是因为 K6工具初始化连接池不同将会导致 「latency小,response大的问题」?如果是该原因,其原因是?

又重新看了一下最上面的数据,带 where 和不带 where 的 latency 差异比较小,还是建议多弄一下数据,尽量使 latency 大一点,这样数据会比较明显。

  1. latency 是 graph 接收请求到将数据返回客户端的时间,包含了 graph 和 storage 之间的请求耗时。
  2. k6 的压测工具,一旦单个线程收到 graph 返回,就会立刻再请求 graph。
  3. 带 where 不会不带 where 多一次条件判断,理论上,如果 graph 和 storage 之间的请求耗时一样,不带 where 的 latency 会更小一些。

然后猜测的话,因为你是 3 台机器都有 storage 和 graph,graph 返回给客户端的出口网络和 storage 返回 graph 是同一个。如果 response 小,意味着客户端和 graph 之间发了更多的请求,占用更多的网络,你可以查一下机器的出口网络是不是打满了。

hey 想问下 v2.5.1 下安装 k6-plugin 有没有需要 checksum mismatch 的问题

已解决 checksum mismatch 了哈,谢谢反馈。

浙ICP备20010487号