EarthChen commented on PR #15983: URL: https://github.com/apache/dubbo/pull/15983#issuecomment-3728127760
# Why 16KB `allocationQuantum` Improves HTTP/2 Performance In HTTP/2's `WeightedFairQueueByteDistributor`, the `allocationQuantum` defines the maximum number of bytes allocated to a stream before the distributor moves to the next stream in the queue. Setting this to **16KB** is an industry-standard optimization for balancing throughput and fairness. --- ## 1. Alignment with HTTP/2 Frame Architecture The default `SETTINGS_MAX_FRAME_SIZE` for most HTTP/2 implementations is **16,384 bytes (16KB)**. * **Reduced Logic Cycles:** If the quantum is smaller than the frame size (e.g., 1KB), the distributor must run its complex weighting logic 16 times just to produce one full 16KB data frame. * **Optimal Framing:** Setting the quantum to 16KB allows the distributor to grant enough "credit" for exactly one full frame in a single allocation cycle, significantly reducing CPU overhead. --- ## 2. Efficiency vs. Fairness (The "Goldilocks" Zone) The distributor manages a classic trade-off: * **Too Small (< 4KB):** High "fairness" but low throughput. The system spends too much time switching between streams (context switching), leading to fragmented writes and high CPU usage. * **Too Large (> 64KB):** High throughput but low fairness. Large streams (like a 5MB image) can "hog" the connection, causing **Head-of-Line (HoL) Blocking** for small, critical resources like CSS or API responses. * **The 16KB Choice:** It is large enough to keep the TCP "pipe" full and minimize system calls, but small enough to ensure that high-priority streams can still "interleave" frequently. --- ## 3. Impact on the Network Stack * **System Call Reduction:** Larger allocations allow the application to pass bigger buffers to the socket at once. This reduces the frequency of expensive `write()` system calls. * **TCP Congestion Control:** 16KB chunks help maintain a steady flow of data that fits well within modern TCP Congestion Windows (CWND), preventing the "stuttering" effect caused by sending many tiny packets. --- ## Comparison Table | Feature | Small Quantum (e.g., 1KB) | **16KB Quantum (Optimized)** | Large Quantum (e.g., 128KB) | | :--- | :--- | :--- | :--- | | **CPU Overhead** | High (Heavy scheduling) | **Low (Efficient)** | Minimal | | **Multiplexing** | Granular / Very Fair | **Balanced** | Poor (Coarsened) | | **Throughput** | Suboptimal | **High** | Maximal | | **Latency (TTFB)** | Low | **Low** | High (Potential blocking) | --- ## Implementation Example (Netty) ```java // Initialize the distributor with the current connection WeightedFairQueueByteDistributor dist = new WeightedFairQueueByteDistributor(connection); // Optimization: 16KB quantum size to balance fairness and high-throughput performance. // This aligns with the default HTTP/2 MAX_FRAME_SIZE. dist.allocationQuantum(16 * 1024); // Apply the distributor to the remote flow controller remoteFlowController.byteDistributor(dist); -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
