apache
Support start KeepWrite bthread urgent
What problem does this PR solve?
Issue Number: resolve #2588
Problem Summary:
What is changed and the side effects?
Changed:
Side effects:
-
Performance effects(性能影响):
-
Breaking backward compatibility(向后兼容性):
Check List:
- Please make sure your changes are compilable(请确保你的更改可以通过编译).
- When providing us with a new feature, it is best to add related tests(如果你向我们增加一个新的功能, 请添加相关测试).
- Please follow Contributor Covenant Code of Conduct.(请遵循贡献者准则).
absl 4038192a57cb75f7ee671f81a3378ff4c74c4f8e 中删除了 flags 库，当前使用的最新的 absl 20240116.1 没有 flags 库了，我看下怎么识别下依赖
这个优化会有实际效果吗，如果启动了KeepWrite线程，说明之前的write已经写不进去了，这时再立即KeepWrite，是不是也会写不进去，最终还是要等待epollout
不一定是写不进去。大多数情况应该是StartWrite写完队头数据，但是队列里还有还有其他数据，所以启动协程KeepWrite。
不过 #2588 在压力比较大的时候，整体服务能力都下降了。只优化少数连接上的rpc回包延迟，优化应该有限吧。
另外最新版的 protobuf（26.1）又改接口了，目前测 protobuf 22+ ci 安装的最新版的 protobuf，应该不久又会有问题🤦
@wasphin 果然，又有问题了
不一定是写不进去。大多数情况应该是StartWrite写完队头数据，但是队列里还有还有其他数据，所以启动协程KeepWrite。
不过 #2588 在压力比较大的时候，整体服务能力都下降了。只优化少数连接上的rpc回包延迟，优化应该有限吧。
那如果是只写了一个req，队列里面还有其它数据，这种情况要是优化，可以让StartWrite去再取后边的请求，也不用再专门启动一个bthread吧。
不一定是写不进去。大多数情况应该是StartWrite写完队头数据，但是队列里还有还有其他数据，所以启动协程KeepWrite。 不过 #2588 在压力比较大的时候，整体服务能力都下降了。只优化少数连接上的rpc回包延迟，优化应该有限吧。
那如果是只写了一个req，队列里面还有其它数据，这种情况要是优化，可以让StartWrite去再取后边的请求，也不用再专门启动一个bthread吧。
不可行吧。调用方的预期是写完自己的req就得返回了，后续还有其他逻辑执行。
不一定是写不进去。大多数情况应该是StartWrite写完队头数据，但是队列里还有还有其他数据，所以启动协程KeepWrite。 不过 #2588 在压力比较大的时候，整体服务能力都下降了。只优化少数连接上的rpc回包延迟，优化应该有限吧。
那如果是只写了一个req，队列里面还有其它数据，这种情况要是优化，可以让StartWrite去再取后边的请求，也不用再专门启动一个bthread吧。
不可行吧。调用方的预期是写完自己的req就得返回了，后续还有其他逻辑执行。
上面有个_write_head.exchange，这块如果fd有写的话，这个请求就挂到链表里面就返回了，下面的判断逻辑就不生效了吧？这块怎么理解呢？有时候起作用，有时候不起作用吗？
我理解是要么同步写自己的req，要么异步写。
那即使加这个start_urgent，也可能是异步写对吧？因为可能走不到这个分支就提前return了。
我理解是要么同步写自己的req，要么异步写。
那即使加这个start_urgent，也可能是异步写对吧？因为可能走不到这个分支就提前return了。
是的
我理解是要么同步写自己的req，要么异步写。
那即使加这个start_urgent，也可能是异步写对吧？因为可能走不到这个分支就提前return了。
是的
那如果走到了下面的分支，说明本请求所在的线程获得了写的权限，它会把自己的请求写完，即使不启动start_urgent，启动start_urgent的目的是为了让后续的请求更及时的写到socket？