（1）是否存在客户端单k6实例，有并发压测的上线限制？
（2）代码里的responseTime指标计算位置，是否会有大量耗时的操作？
https://github.com/vesoft-inc/k6-plugin/blob/master/pkg/nebulagraph/client.go
这个是什么意思？
你是说 responseTime 比 latency 大很多？
代码可以移上去，但是那部分耗时不多的，主要的耗时其实就是 Execute。
Execute 里面，包含了从网络读数据 + 解码，你看一下语句返回的数据是不是特别多，然后网络是不是万兆的网络。
只执行其他部分的代码逻辑，注释掉真正与服务器端交互的session.execute(ngql) 代码。其他代码可以达到20w/s，但是一真正执行这端代码，速度就降下来了，速率最终只能保证1min 达到20w并发
我测的是写请求，应该不会返回数据的，所以解码耗时不应该太多呀。
（1）测小并发情况，responseTime 和 latency 差别不大
✓ IsSucceed
█ setup
█ teardown
checks...............: 100.00% ✓ 61 ✗ 0
data_received........: 0 B 0 B/s
data_sent............: 0 B 0 B/s
iteration_duration...: avg=17965.62µs min=162.03µs med=1988.14µs max=1001274.62µs p(90)=2765.64µs p(95)=3089.21µs p(99)=383531.16µs p(99.9)=939500.27µs p(99.99)=995097.19µs count=63
iterations...........: 61 0.999823/s
latency..............: avg=978.442623 min=748 med=944 max=1409 p(90)=1155 p(95)=1241 p(99)=1352.6 p(99.9)=1403.36 p(99.99)=1408.436 count=61
responseTime.........: avg=1341.016393 min=1082 med=1290 max=2471 p(90)=1536 p(95)=1638 p(99)=2036 p(99.9)=2427.5 p(99.99)=2466.65 count=61
vus..................: 5 min=0 max=5
vus_max..............: 5 min=5 max=5
（2）测大并发情况，responseTime 就比 latency 差特别多了
✗ IsSucceed
↳ 99% — ✓ 209543 / ✗ 28
█ setup
█ teardown
checks...............: 99.98% ✓ 209543 ✗ 28
data_received........: 0 B 0 B/s
data_sent............: 0 B 0 B/s
dropped_iterations...: 40396 641.963126/s
iteration_duration...: avg=1729809.49µs min=1875.29µs med=1387524.48µs max=12759982.12µs p(90)=3580881.74µs p(95)=4608155.70µs p(99)=6403124.49µs p(99.9)=8490227.54µs p(99.99)=9520253.53µs count=209573
iterations...........: 209571 3330.449903/s
latency..............: avg=610.087421 min=458 med=597 max=5689 p(90)=682 p(95)=729 p(99)=855 p(99.9)=1175.72 p(99.99)=4898.645 count=209571
responseTime.........: avg=236091.803599 min=763 med=75123 max=8208297 p(90)=631186 p(95)=833017 p(99)=2014943.9 p(99.9)=4613111.87 p(99.99)=6083223.16 count=209571
vus..................: 9052 min=0 max=9052
vus_max..............: 9052 min=9000 max=9052
所以整体对比，latency并发大的情况下，表现稳定，responseTime延迟越来越大，导致整体并发上不去
以上是单k6实例的测试，我认为客户端既然发的并发数量请求上不去，我就测试了一下同时开了3个k6实例，同时进行压测，发现客户端还是都达到1min 20w，然后服务器端接收到的请求明显翻了三倍。
所以根据以上现象，想问一下，（1）我单实例并发上不去的原因在哪里？
（2）开多个k6实例同时压测是不是也能达到效果？
上面的测小并发情况和大并发都是写语句把？一个 execute 有多少条数据？
是的，大并发小并发都是一样的语句，一个execute只执行一个写入语句，vlaue里面只有一批数据
看着客户端和服务器端机器流量都不大，每秒15M左右，还没打满
经过查询起k6实例的机器性能监控，发现起6个实例，64 cpu的机器负载已经达到122，远超机器性能，感觉目前这里是性能瓶颈
我在我们 128c 物理机上测过读，1w 的并发不会这么高的负载，等我有时间测一下写。
你每个协程写的数据是写死一样的，还是从 csv 文件里读的？
起 6 个实例，每个实例 1w 的并发么。。
机器配置：64c
数据生成：使用的SharedArray读取csv，获取固定的一行，然后动态生成vid进行插入
并发方式使用的： executor: ‘constant-arrival-rate’ 方式
rate设置：3500
方式：同台机器起6个k6实例，本来每个1min后应该执行20w次，结果却是10w次count
running (1m01.4s), 000/300 VUs, 102151 complete and 0 interrupted iterations
first ✓ [ 100% ] 000/300 VUs 1m0s 3500 iters/s
✓ IsSucceed
█ setup
█ teardown
checks...............: 100.00% ✓ 107238 ✗ 0
data_received........: 0 B 0 B/s
data_sent............: 0 B 0 B/s
dropped_iterations...: 102752 1662.930198/s
iteration_duration...: avg=128958.66µs min=1735.79µs med=83200.02µs max=1533837.30µs p(90)=300066.34µs p(95)=392502.23µs p(99)=585625.11µs p(99.9)=853357.62µs p(99.99)=1107363.51µs count=107240
iterations...........: 107238 1735.531266/s
latency..............: avg=608.783752 min=457 med=600 max=6537 p(90)=674 p(95)=707 p(99)=796 p(99.9)=1153.104 p(99.99)=4774.0472 count=107238
responseTime.........: avg=7371.258621 min=786 med=2846 max=575489 p(90)=18515 p(95)=25659 p(99)=46375.15 p(99.9)=122007.422 p(99.99)=289102.1039 count=107238
vus..................: 300 min=0 max=300
vus_max..............: 300 min=300 max=300
机器负载监控
我一直以为用的普通的模式。。
你是开启了 constant-arrival-rate，然后每秒发 3500 个，如果 vu 是 300，就要求每个 vu 1 秒内发 10 个 execute （100ms)。
当做不到 10 个的时候，他就会把剩下的 iterations 当成 drop 处理了，所以 dropped_iterations + iterations = 1662.930198/s + 1735.531266/s = 3500
你可以先不开启 constant-arrival-rate，然后看 300 并发的 qps 是多少，然后 rate 想准一点的话，不要超过这个 qps。
另外就是当不开启 constant-arrival-rate 时，比较一下 iteration_duration 和 responseTime，理论上这俩值不会相差太多，如果相差多了，就是要么准备数据耗时多，要么 vu 之间有锁竞争。
解决了，使用SharedArray有锁竞争导致的问题，不用这个就好了。
但是并发上去以后，无法正常返回压测结果，提示
ERRO[0052] failed to handle the end-of-test summary error="failed to open connection, error: failed to verify client version: read tcp :35946->::9669: i/o timeout \n\tat go.k6.io/k6/js/common.Bind.func1 (native)\n\tat
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。
