wwbmmm commented on issue #2000:
URL:
https://github.com/apache/incubator-brpc/issues/2000#issuecomment-1327211987
>
> 我测试了一下，确实worker少的时候，write的开销也较小。深层原因是什么呢？线程数越少？write落在同一个CPU核上的概率越高，cpu
cache失效的概率越低，性能越好？对吗？
是的
--
This is an automated message from the Apache Git Service.
wwbmmm commented on issue #2000:
URL:
https://github.com/apache/incubator-brpc/issues/2000#issuecomment-1326939893
独立的io线程性能不一定会好，因为存在io线程和process线程之间同步的开销
你这里减小pthread worker的数量（最小是4），应该会好一些
--
This is an automated message from the Apache Git Service.
To respond to the message,
wwbmmm commented on issue #2000:
URL:
https://github.com/apache/incubator-brpc/issues/2000#issuecomment-1326332240
> write和read是在ProcessEvent内部执行的，还在PthreadA上执行。
这个请求是在pthread A 执行，下一个请求就到pthread B（接收了epoll
bthread的那个pthread）执行了呀。每个请求都换pthread，这样效率就降低了
--
This is an automated
wwbmmm commented on issue #2000:
URL:
https://github.com/apache/incubator-brpc/issues/2000#issuecomment-1325979641
>
不不，我的重点不是当前bthread挂起并signal其它的worker来继续执行这个bthread带来的性能损耗，我的重点是经过bthread的ProcessEvent并没有切换pthread，为何系统调用函数write和read的开销高于直接调用ProcessEvent时的系统调用函数write和read的开销。
wwbmmm commented on issue #2000:
URL:
https://github.com/apache/incubator-brpc/issues/2000#issuecomment-1325927072
bthread_start_urgent会把当前pthread的栈切到ProcessEvent函数，同时也会将当前bthread挂起并signal其它的worker来继续执行这个bthread，所以会对性能带来一定影响。并不是jumpstack带来的影响。
--
This is an automated message from the
wwbmmm commented on issue #2000:
URL:
https://github.com/apache/incubator-brpc/issues/2000#issuecomment-1324605671
brpc是多线程的，存在多线程调度延时，而原生redis service是单线程的，没有这个问题，所以没有可比性。
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and
