go语句并发性能测试问题

  • nebula 版本:v2.0.0
  • 部署方式:分布式(3台)
  • 硬件信息
  • 磁盘:SSD
  • CPU、内存信息:8核、64g

我使用javaclient,测试go语句并发性能,当并发线程数提高并且cpu,内存等硬件资源并没有达到瓶颈的时候,相同的单个查询时间会变长,比如:我起10个线程并发时,每个线程执行相同查询的完成时间平均为400ms,当我起40个线程并发时,每个线程执行相同查询的完成时间平均为1000ms。
请问这是什么原因造成的?

我的java程序如下所示:

我的数据包含5亿个点和7亿个边。

在起40个线程同时执行的情况下,服务器的负载情况如下,cpu,内存,io都没有达到瓶颈:

完成时间平均为400ms


这个时间是怎么统计的?然后 query 的语句是多少跳的,大概的数据规模是怎么样,返回多少条?
如果数据多的话,网络带宽也有可能是瓶颈,那就在看一下你压测的程序和 nebula 之间,graph 和 storage 之间的网络带宽怎么样。

PS:

  1. nebula-bench/third at master · vesoft-inc/nebula-bench · GitHub 里面我放了监控的 docker-compose,搭建监控会更方便一点。
1 个赞

我是封装成接口用jmeter测试得出的,jmeter每调一次接口就会进行一次查询,query 的语句是0-3跳。
总体的数据量我在上面说过了,包含5亿个点和7亿个边,每次查询返回5093条名字数据,复制到记事本大概150KB。

query语句:"GO 0 TO 3 STEPS FROM ‘id’ OVER same_phone,same_address,same_website,same_web_email,same_history_phone,same_history_website,same_history_address,same_history_email,same_proper_name,EXEC,HEXEC,PEXEC,LR,SH,branch,HSH,SC BIDIRECT YIELD $$.E.name; ";

你可以在压测的过程中,在 console 执行一下一样的语句,看看时间和工具是不是差不多来比对一下。
然后并发 40 的时候,qps,就是吞吐量有什么样的变化。

我自己测 go 3 跳的时候,并发数从 10 到 40,每个请求的 latency 变大,但是 qps 是变多的。
我的语句返回大概 30w+ 的点,然后监控上看网络已经使用蛮高了,(最高 160Mb/s)。

go 3 跳,每一跳的结果都有 graph 和 storage 之间的网络通信,看看是不是网络的瓶颈。

2 个赞

应该是网络的问题了,之前是拿外网测得,刚才拿内网测试下来吞吐量和cpu使用率明显上去了,我看服务间网络通信也有140Mb/s。但是io的利用率还是很低和之前差不多,理论上所有数据都要从磁盘读,为什么io利用率一直不高呢,是有什么配置文件可以控制的吗?

并不是所有数据都要从磁盘读的,有数据缓存在 cache,那就不用从磁盘读了。
为什么你想要从磁盘读,从磁盘读会更慢的。

你可以看一下 storage 机器的 mem cache,如果想验证磁盘 io 的话,可以手动清一下 cache

echo 3 > /proc/sys/vm/drop_caches

该话题在最后一个回复创建后7天后自动关闭。不再允许新的回复。

浙ICP备20010487号