Wenju Gao
Wenju Gao
@xiaotushaoxia 赞，这个 diff 是标准网络库和 netpoll 实现上没有完全对齐。我记录一个 TODO，有兴趣的话也非常欢迎 PR 哈~
netpoll的shutdown其实是符合预期的：进入graceful阶段会将正在进行中的响应置为短连接，若所有长链接都被正常关闭后则提前退出，否则等待到用户配置的最大退出时间。 标准网络库如果要对齐的话可以按照这个行为来对齐。 直接在graceful进入的时刻批量关闭所有idle状态的链接，这个行为我不认为比上述行为更优：它并不会额外降低连接关闭时刻的并发问题。并且仅是在idle连接退出时间上的一点区别。
@zhouguanglong1 这个是符合预期的，大概率是因为你的链接没有关闭（浏览器默认都是长链接），这个可以本地使用telnet模拟，关闭链接的话直接ctrl-C就可以。
先保留吧，这个变更可能会对用户体验f带来 break change
增加一个revert前后的perf火焰图+benchmark数据看看哈
感谢，我晚些时候看看，影响面应该在使用内置`NewChunkedBodyWriter`劫持response body writer做按需flush的场景。
diff看着不太清楚，可以rebase压缩成一个commit吗？
使用wrk本地测了一下sse的quickstart示例，with pool vs no pool分别做了两轮测试，看起来有池化和没有池化对时延的影响并不明显：  env： go version go1.18.6 darwin/arm64 CPU测试水位 80-90% 稍后我再确认一下CPU采样和更仔细的CPU水位对比
过压状态结论相似： 
@Skyenought 或许可以分享一下你上面的压测程序，我本地再尝试一下