Conversation
The session writer flushed after every frame, so each small frame cost one syscall and one TCP segment. It now feeds the frames already queued and flushes once.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (3)
Included review availability: Your plan provides up to 2 included reviews per hour; 1 remains after this review. Walkthrough
Priority: ⬇️ Low 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches✨ Simplify code
Warning Some tools did not complete. Review the errors below. 🔧 Clippy (1.98.0)Clippy execution timed out Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
The problem
Fanning out to ~2400 WebSocket viewers, 66% of the relay's
sendtocallscarried 8–15 bytes, and 51% of outbound packets were under 64 bytes. Every
frame is flushed as it is written, so small writes never coalesce — each one
costs a syscall, a segment and an ACK.
The change
Writergainsfeedandflush. The writer feeds the frames already queued —up to 64 KiB or 256 frames, in the existing priority order — then flushes once.
Each qmux frame is still its own WebSocket message; only the flush is shared.
Both methods have defaults that keep today's behaviour, so an external
impl Writercompiles and behaves unchanged. No public signature changed.Measured
FreeBSD 15.1, 8 vCPU. Same host, same publisher, same load, before and after:
sendto/sTests
New:
queued_frames_are_fed_then_flushed_oncequeues a three-write media frameand asserts it produces one flush instead of three, with payloads and stream
offsets unchanged. It fails against
main.