Hyper slowness issue

[gvanem]

I did this

Trying to transfer 3 URLs like:

https://api.adsb.lol/api/0/route/SAS4133 
https://api.adsb.lol/api/0/route/BBD6810
https://api.adsb.lol/api/0/route/THY19Y

to get Airplane flight-information (in series or parallel), causes curl to hang for a really long time between each URL.
But only when built with -DUSE_HYPER !? Entering the URLs either from a config-file or set on the command-line doesn't matter.
A simple get-urls.bat file to reproduce:

@echo off
setlocal
set CURL_SSL_BACKEND=schannel
echo url=https://api.adsb.lol/api/0/route/SAS4133  > %TEMP%\curl_urls.txt
echo url=https://api.adsb.lol/api/0/route/BBD6810 >> %TEMP%\curl_urls.txt
echo url=https://api.adsb.lol/api/0/route/THY19Y  >> %TEMP%\curl_urls.txt
curl -s -K - < %TEMP%\curl_urls.txt | grep "_airport_codes_iata"

Running the above .bat file takes at least 1 minute to complete! With --parallel or not.

I expected the following

The transfer to complete in < 1 sec. as the curl.exe bundled with Win-10 does:

timer & c:\windows\system32\curl.exe -s https://api.adsb.lol/api/0/route/SAS4133 https://api.adsb.lol/api/0/route/BBD6810 https://api.adsb.lol/api/0/route/THY19Y | grep "_airport_codes_iata"  & timer
Timer 1 on:  9:42:26
  "_airport_codes_iata": "CGN-BLL-KEF",
  "_airport_codes_iata": "SFO-IST",
  "_airport_codes_iata": "BGO-SVG",
Timer 1 off:  9:42:26  Elapsed: 0:00:00,45

c:\windows\system32\curl -V
curl 8.0.1 (Windows) libcurl/8.0.1 Schannel WinIDN
Release-Date: 2023-03-20

Adding the --parallel option I'd assume the URLs would be issued in parallel. Doesn't look so to me.

Version info:

curl -V
curl 8.2.0-DEV (x86_64-pc-win32) libcurl/8.2.0-DEV (OpenSSL/3.2.0) Schannel 
  (rustls-ffi/0.10.0/rustls/0.21.0) zlib/1.2.12 brotli/1.0.9 zstd/1.5.2 c-ares/1.19.0 libssh2/1.10.1_DEV Hyper/1.0.0-rc.3
Release-Date: [unreleased]
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s scp sftp smb smbs smtp 
  smtps telnet tftp ws wss
Features: alt-svc AsynchDNS brotli HSTS HTTP2 HTTPS-proxy Kerberos Largefile libz MultiSSL NTLM SPNEGO SSL SSPI threadsafe 
  TLS-SRP UnixSockets zstd

I'm on Windows-10, 22H2 (OS-build 19045.2965).

[gvanem]

After updating Rust with:

  rustup update
  rustup toolchain install nightly-x86_64-pc-windows-msvc
  rustup override set nightly-x86_64-pc-windows-msvc

a git pull of Hyper's master and rebuilding everything, this issue persists.

[bagder]

Reproduces for me as well on Linux.

[icing]

Added some debug info's to this. I see that in Curl_hyper_stream()which is called by curl's transfer loop:

1. socket gives POLLIN event
2. Curl_hyper_stream() is called
3. hyper_waker_wake(h->read_waker) is called
4. socket input reads the HTTP response
5. hyper_executor_poll(h->exec); gives HYPER_TASK_EMPTY
6. Curl_hyper_stream() returns
7. time passes
8. transfer loop calls this transfer again after 100ms or more
9. no POLL event, no hyper_wake..., NO network IO
10. hyper_executor_poll(h->exec); gives HYPER_TASK_RESPONSE

this explains the "slowness" of handling hyper transfers.

Experimentally, if I change step 5 to call hyper_executor_poll(h->exec); a second time, directly after the EMPTY result, it delivers HYPER_TASK_RESPONSE and the transfers are fast.

This seem to be y hyper internal synchronization issue that make IO result not available though they have been processed internally. Only when calling the hyper poll function again, the result is returned.

[gvanem]

@icing

Only when calling the hyper poll function again, the result is returned.

Hope someone (you?) is working on a fix. I'm clueless about such internal details.

[icing]

@gvanem you are right. I wanted to document my observations to drag the hyper project in. I think this is a bug on their behalf, but if the insist everything is fine, we'll make a workaround in curl.

[icing]

Opened hyperium/hyper#3237

[bagder]

We also have #10803 as known bug now. It is a memory-leak with hyper as a backend.

[icing]

On advisement of @seanmonstar I made some small changes that resolve the slowness for me. Pr in #11344.

I see our http/1.1 test cases work, h2 has issues with connection reuse.