Building a network stack for optimal throughput / low-latency trade-offs
summary
Flink 1.3 removes brittle buffer config and uses 32KB memory segments, a global and per-subtask local buffer pool, and Netty/TCP for transport; work for 1.4 builds a credit-based flow control where receivers reserve buffers and advertise credits, and an event-driven pull (replace output flusher) to avoid artificial 100ms flush tradeoffs. A prototype shows near-zero latency for very sparse sources while throughput is currently between the old zero-timeout low and the full-throughput high (target improvements ongoing).
AI-written summary · about
chapters (10)
- 0:00Introduction to Flink network stack
- 1:02Current multiplexing approach
- 2:32Record flow and checkpointing
- 5:27Buffer management challenges
- 7:12Latency vs throughput trade-off
- 8:15Planned changes for Flink 1.4
- 11:03Credit-based flow control
- 12:09Benchmark results and trade-offs
- 14:19Event-driven flushing benefits
- 15:02Q&A session
related talks
32mGetting into Low-Latency Gears with Apache Flink
39mNetty 5: Lessons Learned
45mReducing Network Latency: Innovations for a Faster Internet
21mAccelTCP: Accelerating Network Applications with Stateful TCP Offloading
16mPacket Order Matters! Improving Application Performance by Deliberately Delaying Packets
28mCreating Memory Efficient and High Performance IP Stack for Zephyr OS
29mWhen your stream doesn't stream very well
24mConfluo: Distributed Monitoring and Diagnosis Stack for High-speed Networks