我使用javaclient，测试go语句并发性能，当并发线程数提高并且cpu，内存等硬件资源并没有达到瓶颈的时候，相同的单个查询时间会变长，比如：我起10个线程并发时，每个线程执行相同查询的完成时间平均为400ms，当我起40个线程并发时，每个线程执行相同查询的完成时间平均为1000ms。
请问这是什么原因造成的？
我的java程序如下所示：
我的数据包含5亿个点和7亿个边。
在起40个线程同时执行的情况下，服务器的负载情况如下，cpu，内存，io都没有达到瓶颈：
完成时间平均为400ms
这个时间是怎么统计的？然后 query 的语句是多少跳的，大概的数据规模是怎么样，返回多少条？
如果数据多的话，网络带宽也有可能是瓶颈，那就在看一下你压测的程序和 nebula 之间，graph 和 storage 之间的网络带宽怎么样。
PS：
我是封装成接口用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 之间的网络通信，看看是不是网络的瓶颈。
应该是网络的问题了，之前是拿外网测得，刚才拿内网测试下来吞吐量和cpu使用率明显上去了,我看服务间网络通信也有140Mb/s。但是io的利用率还是很低和之前差不多，理论上所有数据都要从磁盘读，为什么io利用率一直不高呢，是有什么配置文件可以控制的吗？
并不是所有数据都要从磁盘读的，有数据缓存在 cache，那就不用从磁盘读了。
为什么你想要从磁盘读，从磁盘读会更慢的。
你可以看一下 storage 机器的 mem cache，如果想验证磁盘 io 的话，可以手动清一下 cache
echo 3 > /proc/sys/vm/drop_caches
该话题在最后一个回复创建后7天后自动关闭。不再允许新的回复。