curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Subtle H2 performance degradation in 8.7.1 vs 8.6.0

From: Dmitry Karpov via curl-library <>
Date: Fri, 29 Mar 2024 22:47:48 +0000

Hi All,

Trying 8.7.1 and TOT, I discovered a subtle performance degradation for H2 transfers vs 8.6.0, which I would like to report.

It is subtle because it is mostly visible on low-end hardware platforms with weak CPUs in cases when a client application needs to perform heavy processing of incoming data (i.e. JSON parsing and processing).
I stepped on small performance degradation with 8.7.1 when I analyzed overall H2 transfer time metrics in my application which included total transfer process time (download + processing).

As it turned out, 8.7.1 (and TOT) processes H2 transfers with a larger number of write callbacks than 8.6.0, and with smaller chunk sizes.

Here is the illustration for two H2 multiplexed 1MB transfers downloaded over LAN:

8.6.0, 2 H2, LAN: **** chunks=134, min_size=36, max_size=16384, avg_size=15650, time=32ms,
       <size:count map> [36:1, 117:1, 149:1, 230:1, 567:2, 16100:2, 16375:122, 16384:4]

8.7.1, 2 H2, LAN: **** chunks =146, min_size=45, max_size=16375, avg_size=14364, time=36ms,
      <size:count map> [45:8, 158:8, 576:2, 16217:8, 16330:8, 16375:112]

As we can see from the example data, 8.7.1 had smaller data chunks on average (14364 vs 15650),
the total number of chunks was greater (146 vs 134), and the full CURL_MAX_WRITE_SIZE (16384) was never used.

(A similar picture if I use just one H2 download and slower speeds).

While it is not an issue for fast CPUs, a bigger number of write callbacks with smaller sizes might affect overall transfer performance on slow CPUs.
So, I thought it could be helpful to provide feedback from this perspective.

Dmitry Karpov

Received on 2024-03-29