zhouyanghere
zhouyanghere
不嫌弃的话，当然很乐意啊。哈哈。
有没有办法在低压力下提供低延时又在高压力下高吞吐。
可能我描述的不是很清楚，和多线程应该没有直接关系。其他的类redis数据库，比如DragonFly DB，延时也很低。 我对ProcessEvent加了bvar统计，如果ProcessEvent走bthread，则ProcessEvent函数的处理平均耗时为26us。如果不走，则ProcessEvent只有6us。单链接下最明显。 所以，我奇怪的是，ProcessEvent在redis协议下处理很简单，主要是系统调用read和write。而且ProcessEvent在bthread里调度时，自身并没有切线程，只是线程将函数调用栈从Socket::StartInputEvent切换到ProcessEvent函数,为何会影响系统调用read和write的开销呢？
Socket::StartInputEvent 里如果直接调用ProcessEvent函数，也是函数调用过程和栈切换，为何brpc jumpstack就能影响系统调用。是否和jumpstack的处理有关系？jumpstack是汇编代码，能力有限，看不大懂。
如果将进程用taskset绑定到固定的CPU上，也没有此差异。是不是brpc jumpstack的过程导致线程pthread切换了CPU，导致了cache miss，从而影响系统调用的开销。
不不，我的重点不是当前bthread挂起并signal其它的worker来继续执行这个bthread带来的性能损耗，我的重点是经过bthread的ProcessEvent并没有切换pthread，为何系统调用函数write和read的开销高于直接调用ProcessEvent时的系统调用函数write和read的开销。
> 它处理过程是这样的。Pthread A上运行bthreadA（epoll_wait）,然后处理epoll事件，即ProcessEvent过程，其为bthread B，PthreadA会去执行bthread B，而将bthread A丢给队列，由其他pthread去继续执行。write和read是在ProcessEvent内部执行的，还在PthreadA上执行。 之前怀疑pthread 在bthread调度过程中切换了cpu，线程绑核后并没有效果。 之所以怀疑jump stack，因为jump stack各系统实现的汇编代码不同，而mac pro上ProcessEvent是否基于bthread没有任何区别。当然也有可能是CPU架构或操作系统不同的原因。 现在就是不清楚ProcessEvent走bthread影响系统调用的真实原因具体在哪里，从而无法进行优化。
还有一个原因可能是因为同1个socket的write调用一直在不同的线程里切换导致开销变高？因为看其他的网络框架，一般socket会绑到一个固定io线程处理。
> 那感觉是不是还是像其他网络框架那样，io线程和socket是绑定的，只是rpc process那里用bthread去做负载均衡要好一点呢？这样也可以避免长尾请求的阻塞效应。
> 独立的io线程性能不一定会好，因为存在io线程和process线程之间同步的开销 你这里减小pthread worker的数量（最小是4），应该会好一些 我测试了一下，确实worker少的时候，write的开销也较小。深层原因是什么呢？线程数越少？write落在同一个CPU核上的概率越高，cpu cache失效的概率越低，性能越好？对吗？