GitHub user lizining1231 added a comment to the discussion: [OSPP 2026] Triple 协议性能分析与优化
# fastpath大报文场景下负收益原因 1MiB场景下 优化前后火焰图diff <img width="1916" height="911" alt="image" src="https://github.com/user-attachments/assets/9186ea4c-423c-4a6f-ac32-7529ee097a66"; /> 1MiB场景下 优化前 memmove展开 <img width="1913" height="917" alt="image" src="https://github.com/user-attachments/assets/a811f24d-47c0-498f-a7ad-63b298bcdec9"; /> 1MiB场景下 优化后 memmove展开 <img width="1907" height="918" alt="image" src="https://github.com/user-attachments/assets/20654376-c2d4-450c-b286-0f14c7e566a2"; /> 采样时间相同，duplex 33.15s / 19.70% → fastpath 36.99s / 21.26%。fastpath 在 `bytes.Buffer` 里先 Write 再 Read 整包交给传输层，同一条 1MiB 数据比 duplex 的 `io.Pipe` 流式管道多传输一遍，所以大报文下 fastpath 收益整体为负。 fastpath 节省的是固定开销，而同时存在会随报文增大而增大的可变开销。在128B报文下，每请求成本里io.pipe的固定开销在总开销中占比很高，fastpath 省下的收益 ＞其带来的拷贝代价 在1MiB报文下，每请求 ~4ms 被 gzip 压缩（23%）和传输（20%）占满，固定开销占总开销比例趋零，收益也 ≈ 0，同时拷贝开销随报文增大而增大，存在负收益。 从源码来看，池化 `bytes.Buffer`直到 `CloseWrite` 才同步发起请求，传输层再从该 buffer 整包读走，**同一份 1MiB 数据在内存里被 Write + Read 运输两遍**。而原 duplex 路径直接把 payload 写入 `io.Pipe`，net/http 边读边发，数据只运输一次。 duplex（流式，不囤积）： ```go func (d *duplexHTTPCall) Write(data []byte) (int, error) { ... // 写入 io.Pipe，net/http 边读边发，数据仅运输一次 return d.requestBodyWriter.Write(data) } ``` fastpath（整包囤积 + 二次搬运）： ```go // 先整包囤进内存（第一次搬运） func (c *unaryFastPathCall) Write(data []byte) (int, error) { ... return c.body.Write(data) // 1MiB 拷入 pooled buffer } // 传输层再从 buffer 读走（第二次搬运） func (b *unaryRequestBody) Read(p []byte) (int, error) { ... return b.buf.Read(p) // 1MiB 拷给网络层 } ``` GitHub link: https://github.com/apache/dubbo-go/discussions/3673#discussioncomment-18223400 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
