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.

Thanks,
Dmitry  Karpov

-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Reply via email to