Follow-Up: HTTP/3 Performance Observations with NGINX 1.29.3

Projects NGINX
, ,
1

References to previous posts:

We conducted HTTP/3 performance tests across NGINX versions 1.25.5 to the latest 1.29.3 under consistent network emulation conditions.

Starting from version 1.27.5, NGINX switched its QUIC congestion control algorithm from reno to cubic. While we cannot confirm whether this change is the root cause of performance differences, we suggest that future NGINX releases provide a configuration parameter allowing users to select the QUIC congestion control algorithm based on their deployment needs.

Test Results(Average of 100 runs per version, in seconds)

Version No Packet Loss (sec) 1% Packet Loss (sec)
nginx-1.25.5 12.329 21.339
nginx-1.27.4 13.592 24.173
nginx-1.27.5 27.251 221.720
nginx-1.28.0 19.456 195.452
nginx-1.29.0 19.498 186.282
nginx-1.29.1 20.957 187.009
nginx-1.29.2 16.910 185.894
nginx-1.29.3 23.945 226.876

Test Configuration Summary

  • nginx.conf setting: http3_stream_buffer_size 50m;

  • Network emulation (tc + netem): limit 6000, delay 50ms, packet loss 0% / 1%

  • Test file size: 47MB

Additional Observation

Comparing nginx-1.29.3 with previous versions:

  • Under no packet loss, nginx-1.29.3 (23.945 sec) is slower than nginx-1.29.2 (16.910 sec) and nginx-1.29.1 (20.957 sec), indicating a performance regression.

  • Under 1% packet loss, nginx-1.29.3 (226.876 sec) is significantly worse than nginx-1.29.2 (185.894 sec) and nginx-1.29.1 (187.009 sec).

This suggests that the performance trend under packet loss remains problematic in versions using QUIC cubic. We still recommend that future NGINX releases provide a configuration parameter to allow users to select the QUIC congestion control algorithm based on their needs.

1 Like
2

Hi @villa

You’ve raised an excellent topic! I haven’t yet compared 1.29.3 with previous vers, but as far as I remember, there haven’t been significant quic-related changes that could have such a large impact.

As for Reno vs Cubic, the root cause of the performance anomaly wasn’t the change of the congestion control algorithm, but the overly aggressive cwnd growth in Reno’s congestion control mechanism (see commit cd5e4fa). So, to get a fair comparison of reno vs cubic, you need to measure the performance of Reno + cd5e4fa vs Cubic. In that case, Cubic should be faster.