是否可以直接执行Socket::StartWrite里的KeepWrite?
Socket::StartWrite里的KeepWrite,是不是可以直接调用,不需要起后台bthread。当前session的response已经返回了,直接用当前bthread执行排队的response就可以,不然在压力比较大的时候等其他worker去执行这个bthead,延迟会增加很多
如果直接在当前bthread执行KeepWrite,可能会阻塞异步rpc的CallMethod调用。
如果直接在当前bthread执行KeepWrite,可能会阻塞异步rpc的CallMethod调用。
baidu_rpc_protocol.cpp SendRpcResponse调用socket write的时候,在参数里加个标识是不是可行?
baidu_rpc_protocol.cpp:
socket.cpp:
这样也会影响服务端异步rpc响应吧。Socket::StartWrite里直接调用KeepWrite,会导致Write阻塞,不太合理吧。
加个参数,支持使用bthread_start_urgent原地执行KeepWrite,应该能满足需求。
这样也会影响服务端异步rpc响应吧。Socket::StartWrite里直接调用KeepWrite,会导致Write阻塞,不太合理吧。
加个参数,支持使用bthread_start_urgent原地执行KeepWrite,应该能满足需求。
当前请求的response已经返回了,client端应该是已经结束了。Write阻塞指的是什么?
单纯从Socket::Write接口看就是有可能会阻塞吧。
单纯从Socket::Write接口看就是有可能会阻塞吧。
只有baidu_rpc_protocol.cpp SendRpcResponse调用Socket::Write的时候才会在执行完之后去处理队列里的消息,默认都是使用bthread_start_background
用bthread_start_urgent效果差不多,但是影响更小?
用bthread_start_urgent效果差不多,但是影响更小?
效果应该差不多
@xybanpeng 可以使用 #2591 测试一下优化效果
补充最近我们生产环境遇到的一个 OOM Case 数据,该节点突然接收到较多的读数据请求。
不清楚使用 bthread_start_urgent 在这个 case 里是否会更高效? 另外这里的 bthread_switch 下降较大,是由于出现阻塞性的 bthread 还是因为 BRPC 服务得不到 CPU 时间片(因为这台机器混布其它吃 CPU 服务)