RT
如client一次执行多条查询,将结果以列表形式返回
期望的支持形式:
client增加如下功能
client.executeMulNgql(['ngq1','ngq2','ngql3'])
nebula如果支持对应操作,client我可以自行开发
RT
如client一次执行多条查询,将结果以列表形式返回
期望的支持形式:
client增加如下功能
client.executeMulNgql(['ngq1','ngq2','ngql3'])
nebula如果支持对应操作,client我可以自行开发
反而感觉你可以搞个线程池。。一个线程执行一个语句等结果。。。。
目前是可以采用这种来解决,不过如果能支持一次执行多条查询的查询,也相应减少了ng的io。
一时间大量的client连接,对于ng也是不小的压力。
几千个 client 没啥压力
不行啊。。。
这样并没有啥性能优势,反而可能会有长尾,多线程也不复杂。
多线程是可以解决,我现在用的是python gevent并发100个协程,目测每秒能成功执行200多个(语句都是类似于查询父节点个数),但还是慢啊。
我可以多线程这样怼起来,关键是nebula是否能扛得住(可以一直加)。提升为并发1000个的时候已经有少量timeout了,我还给client加了报错重连。
如果一次能执行多条语句,client与nebula之间的交互就少了很多io
这样也就发请求的数量少了很多,但是回复请求的整体时延由于长尾会明显增加。长尾这段时间client不会发新压力,这样server负载就会很低。感觉不划算啊。
你有注意这个timeout是server端的cpu io不够,还是client端的cpu不够?
确定是server端,client端组的是一个计算集群。
这个长尾指的是?
ABC三个请求一组发过来,必须最慢的那个做完才能返回,通常这个时延至少是单个的1.5倍。
server端硬件大概跑到啥情况,你版本是1.0.x?
server端目前是单机用docker搭的测试,8C 16G,版本1.1.0
三个请求一组的话,client与server交互只有一次io,分别发的话就变成了三次。
io的耗时应该远大于cpu处理耗时。
你可以这样对比下,变相实现了多个请求一个yield
$A=…
$B=…
yield $A.a, $A.b, $B.a, $B.b
多谢,我测试下
但这样就能成功
YIELD不支持多个变量