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: relative performance
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_cool.haxx.se>
Date: Thu, 26 Aug 2021 08:41:35 +0200 (CEST)
On Wed, 25 Aug 2021, XSLT2.0 via curl-library wrote:
> Summary : IMHO the important thing is to test on a "slow enough" machine,
> assuming the main measure you want is "elapsed".
Slow enough for what? I agree that if we run the tests over an actual physical
network, a system with a fast enough CPU will saturate the network and then it
mostly won't matter how fast or not curl is.
For this kind of test to be sensible, we need to make sure to either have a
faster pipe than can be saturated by a single CPU core or do a test setup that
can't do it due to complexity. It seems easiest to accomplish this by doing
transfers on localhost.
When doing transfers on localhost I don't think it matters much exactly how
fast the CPU is, and I'm convinced we will see deltas between versions
whichever CPU we use. In fact, I beleive I've already spotted some. I'm just
not ready yet to draw the conclusions nor to start working on figuring out why
they exist.
I've provided scripts in the curl/relative directory now that can:
1. build 'sprinter' the test tool
2. build (lib)curl for a number of versions and install them locally
3. run sprinter with each of those built versions
All you need to do is edit the run-many.sh script to make sure it uses a URL
on your localhost that works, and adjust how many transfers and which
concurrency to use.
It seems most interesting to do A LOT of smaller transfers with a fairly huge
concurrency. I've played with doing 100,000 4K transfers at 100 at a time and
with 6 8GB transfers at 2 at a time, and the latter will mostly just saturate
the memory bandwidth in the machine.
The output for the sprinter runs is not easily "comparable" yet and there's no
machine help to detect regressions etc but it's a decent start I think.
I'm curious if others will see the same thing I seem to see right now...
Date: Thu, 26 Aug 2021 08:41:35 +0200 (CEST)
On Wed, 25 Aug 2021, XSLT2.0 via curl-library wrote:
> Summary : IMHO the important thing is to test on a "slow enough" machine,
> assuming the main measure you want is "elapsed".
Slow enough for what? I agree that if we run the tests over an actual physical
network, a system with a fast enough CPU will saturate the network and then it
mostly won't matter how fast or not curl is.
For this kind of test to be sensible, we need to make sure to either have a
faster pipe than can be saturated by a single CPU core or do a test setup that
can't do it due to complexity. It seems easiest to accomplish this by doing
transfers on localhost.
When doing transfers on localhost I don't think it matters much exactly how
fast the CPU is, and I'm convinced we will see deltas between versions
whichever CPU we use. In fact, I beleive I've already spotted some. I'm just
not ready yet to draw the conclusions nor to start working on figuring out why
they exist.
I've provided scripts in the curl/relative directory now that can:
1. build 'sprinter' the test tool
2. build (lib)curl for a number of versions and install them locally
3. run sprinter with each of those built versions
All you need to do is edit the run-many.sh script to make sure it uses a URL
on your localhost that works, and adjust how many transfers and which
concurrency to use.
It seems most interesting to do A LOT of smaller transfers with a fairly huge
concurrency. I've played with doing 100,000 4K transfers at 100 at a time and
with 6 8GB transfers at 2 at a time, and the latter will mostly just saturate
the memory bandwidth in the machine.
The output for the sprinter runs is not easily "comparable" yet and there's no
machine help to detect regressions etc but it's a decent start I think.
I'm curious if others will see the same thing I seem to see right now...
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2021-08-26