K6压测，执行match语句，使用where子句导致「吞吐率」差异（必现）

[oliver]

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

[HarrisChu]

几个问题，你可以查一下：

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

[oliver]

感谢回复：

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

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

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

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

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

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

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

[HarrisChu]

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

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

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

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

[oliver]

好的，谢谢。

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

[oliver]

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大的问题」？如果是该原因，其原因是？

@oliver

部署方式（分布式）：

• 201、202、203 部署Nebula Graph集群
• 001 运行压测工具 K6

[HarrisChu]

又重新看了一下最上面的数据，带 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 之间发了更多的请求，占用更多的网络，你可以查一下机器的出口网络是不是打满了。

[bruce.chen]

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

[HarrisChu]

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