You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brpc.apache.org by GitBox <gi...@apache.org> on 2020/07/02 09:08:03 UTC

[GitHub] [incubator-brpc] dangding commented on issue #1149: OnNewMessages中last_msg处理机制,是否会影响请求延时?

dangding commented on issue #1149:
URL: https://github.com/apache/incubator-brpc/issues/1149#issuecomment-652887148


   > 说下我对这个问题的理解哈,这里说的延时应该是指从CutInputMessage得到一个新的msg,到建立的bthread flush之间的延时。
   > 延时来源于两方面:
   > 
   > 1. 一次DoRead得到的所有msg会通过一次bthread_flush被调度执行。
   > 2. last_msg的处理时机会被延后。当次DoRead的last_msg会在下一次DoRead后被QueueMessage,伴随下一次DoRead产生的msg被flush;若当次DoRead后读不到新的数据,last_msg会在析构时在当前bthread执行ProcessInputMessage。
   > 
   > 理论上来说last_msg的延时和一次DoRead的第一个msg是相当的,因此,OnNewMessages中延时主要是上述1)带来的。为什么要这么做,OnNewMessages下面的注释也给出了解释——“To minimize the overhead, scheduling is batched”。
   
   如果单个socket上qps很高,一次DoRead的数据量比较大呢?延时会不会明显?
   
   PS:用echo_server起了一个服务,在另一台机器上通过rpc_press发请求,当qps较大时,通过brpc的监控页面,可以看到,运行时间越长,延时会越来越大。


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@brpc.apache.org
For additional commands, e-mail: dev-help@brpc.apache.org