使用nebula-bench 2.0测试自己的图库语句查询性能
第一次测试，只使用一台graph
指定 ThreadGroup.num_threads = 96
第二次测试，使用两台graph
指定ThreadGroup.num_threads = 200
具体是什么样的语句，数据规模有多大？
机器的配置是多少核多少内存的？
因为性能和很多因素有关系，所以只是加 graph 节点，并不意味着一定是线性增加的。
你可以搭一下监控，然后看看压测过程中，客户端（jmeter的机器），graph，storage 的系统指标，cpu，网络流量，磁盘 io，内存使用等。找到瓶颈，再针对瓶颈调整。
语句是一个match语句，数据量点边大概三千万条，并不是很大，每个节点都创建了索引。
机器是96C，500G，storage配置线程48，black_cache配置100G
match (v:email)-[:emailid]->(mid:id)<-[:phoneid]-(phone:phone)-[:phoneid]->(ids:id) where id(v)=="replace" with v, count(distinct phone) as pnum,count(distinct mid) as midnum,count(distinct ids) as idsnum , sum(ids.isblack) as black where pnum > 2 and midnum>5 and midnum < 100 and idsnum > 5 and idsnum < 300 and black > 0 return v.value1, true as result
后续又测试了一次，这次是重新安装好三节点的集群，版本2.0.1的，启动三个graphd，导入数据后测试，发现并发相比之前确实提高三倍。之前是启动了一台graphd加入到集群中，并发没有变化，但是新加入的节点确实分散到了请求。难道是新加入之后需要blance或者compact吗？
那挺奇怪的，要么你再观察下。
另外，你说的 一台graphd加入到集群 是什么意思，一共 3台机器，graphd 部署在某个机器上，还是新增了一个机器，graphd 部署在新的机器上的？
然后3个 graphd 后，你也是调整了 jmeter 的并发线程数是 300 么？Jmeter 在3个 storage 的机器，还是另一个机器上？
我有4台机器 1,2,3,4，其中1,2,3三台部署了storage，第4台部署了graphd，测试的nebula-bench在第4台上。这时候进行第一次测试。jmter线程设置的是96。
然后我又在三台中选了1启动了graphd，这样该集群就有两个graphd了，想验证增加graphd会不会提高并发，再次测试得到与第一次一样的结果。jmter线程设置的是200
2.0.1版本发布之后，我重新部署了一遍，这次是直接1,2,3三台分别启动了，storage，meta，graphd，然后导入数据，再使用nebula-bench测试，这里jmter线程设置的是96，就是CPU核心数，发现并发相比之前只有一个graphd的时候提高了三倍。
所以挺奇怪的。。。
那要么你下次如果还有问题，再发帖子吧。
可以尽量先用一样的 Jmeter 线程数，然后慢慢调上去。
也可以搭点监控，看看是不是网络打满了。
1、在几百并发下，在内部测试过程中jmeter 不存在性能瓶颈
2、你那边要检查一下服务器的系统负载，网络带宽，如果机器网络被打满了，加并发也是没有用的。
3、只增加graphd，storage 不增加 是没法保证系统就一定性能翻倍
4、性能测试之前：保证数据均匀分布，做compact 这样的场景下性能才好
压测经验丰富
我测试使用的机器和配置都是相同的，storage均为3台，唯一的区别是，
第一次：已有1台graphd，导入数据，测试得到结果700，然后直接增加1台graphd节点进行测试，得到结果700
第二次：先部署好三个graphd，再导入数据进行测试，得到结果2100。
几百的并发是因为我测试的语句是三度较为复杂的。 如果是较为简单的语句单个graphd是可以达到1万以上的。
从第二次结果看，并发量随着graphd增多而线性增长了，但是第一次没得到这个结论，这是奇怪的地方。
之后我还会做相关的测试，如果再发现问题再反馈吧。
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。