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.
Re: asynchronous/mainloop C-API template/model
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Fulup Ar Foll via curl-library <curl-library_at_cool.haxx.se>
Date: Wed, 10 Feb 2021 11:46:41 +0100
Daniel,
I don't thing performance come from protocols. HTTPd servers caching
mechanism should be more or less equivalent in both sync and async
client mode. Especially for example.com that serve only one page.
Nevertheless I agree with you performance difference remains
inexplicably big, but it is very stable and reproducible. Digging deeper
you may see that individual page elapse time remain somehow comparable.
The shift in performance really comes from running all request in //.
When running only one page request, they is not significant difference,
even if async mode seems generally smootly faster.
My impression is that websites/operators limit the performance on a
single httpd connection. As this limit does not apply on multiple
connections, when running // speed limit comes your upload bandwidth and
not from the quality of service server/operator offer to a single
request. It would not be hard to test with 50 URLs on different web
sites, it is just longer to write the test script.
This being said my quest for async was about integration within existing
framework that run asynchronously and imposes their own mainloop.
Performances is a side effect, even if looking at the difference it
probably should deserve some attention.
My main point was about offering a simple libcurl integration within
existing asynchronous frameworks. I lost 2 days making a clean
libcurl/async integration when it should have taken me 2 hours. I
propose my work to curl community in order other member not to loose 2
days like I did :)
Fulup
On 10/02/2021 11:19, Daniel Stenberg wrote:
> On Wed, 10 Feb 2021, Fulup Ar Foll via curl-library wrote:
>
>> - big request (13MB) async mode is 6.5 faster (8s vs 53s)
>> - small request (1KB) async mode is 30 time faster (0.62s vs 19.8s)
>
> Doesn't this just say that doing 50 transfers in parallel to the same
> (HTTP/2 ?) server is faster than doing them one by one in a serial
> fashion?
>
> I'll admit the difference seems unexplainably big.
>
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-02-10
Date: Wed, 10 Feb 2021 11:46:41 +0100
Daniel,
I don't thing performance come from protocols. HTTPd servers caching
mechanism should be more or less equivalent in both sync and async
client mode. Especially for example.com that serve only one page.
Nevertheless I agree with you performance difference remains
inexplicably big, but it is very stable and reproducible. Digging deeper
you may see that individual page elapse time remain somehow comparable.
The shift in performance really comes from running all request in //.
When running only one page request, they is not significant difference,
even if async mode seems generally smootly faster.
My impression is that websites/operators limit the performance on a
single httpd connection. As this limit does not apply on multiple
connections, when running // speed limit comes your upload bandwidth and
not from the quality of service server/operator offer to a single
request. It would not be hard to test with 50 URLs on different web
sites, it is just longer to write the test script.
This being said my quest for async was about integration within existing
framework that run asynchronously and imposes their own mainloop.
Performances is a side effect, even if looking at the difference it
probably should deserve some attention.
My main point was about offering a simple libcurl integration within
existing asynchronous frameworks. I lost 2 days making a clean
libcurl/async integration when it should have taken me 2 hours. I
propose my work to curl community in order other member not to loose 2
days like I did :)
Fulup
On 10/02/2021 11:19, Daniel Stenberg wrote:
> On Wed, 10 Feb 2021, Fulup Ar Foll via curl-library wrote:
>
>> - big request (13MB) async mode is 6.5 faster (8s vs 53s)
>> - small request (1KB) async mode is 30 time faster (0.62s vs 19.8s)
>
> Doesn't this just say that doing 50 transfers in parallel to the same
> (HTTP/2 ?) server is faster than doing them one by one in a serial
> fashion?
>
> I'll admit the difference seems unexplainably big.
>
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-02-10