describe-tests.conf

# This file documents each test to help viewers.

[100G-speed]

Downloads a single 100 gigabyte file over clear-text HTTP/1.1 from an Apache
httpd server running on localhost with the curl tool. The measured network
transfer speed in bytes per second is what the curl tool itself reports.

[single-numallocs]

Downloads a single 512M file over clear-text HTTP/1.1 from an Apache httpd
server running on localhost. Using the built-in memory-tracking, all
allocations done by curl and libcurl are logged and then counted.

[single-maxalloc]

Downloads a single 512M file over clear-text HTTP/1.1 from an Apache httpd
server running on localhost. Using the built-in memory-tracking, all
allocations done by curl and libcurl are logged and then added up. This number
is the peak number of bytes allocated concurrently at any point through the
operation.

[h1parallel-speed]

Downloads 100 files each in 100 parallel transfers, each getting a 500MB file.
Using HTTP/1.1 over HTTPS from an Apache httpd running on localhost. This
measures total throughput in bytes per second.

[h2parallel-speed]

Downloads 100 files each in 100 parallel transfers, each getting a 500MB file.
Using HTTP/2 over HTTPS from an Apache httpd running on localhost. This
measures total throughput in bytes per second.

[h3parallel-speed]

Downloads 100 files each in 100 parallel transfers, each getting a 500MB file.
Using HTTP/3 over HTTPS from a Caddy server running on localhost. This
measures total throughput in bytes per second.

[h1parallel-mem]

Downloads 100 files each in 100 parallel transfers, each getting a 500MB file.
Using HTTP/1.1 over HTTPS from an Apache httpd running on localhost. This
measures the maximum RSS size in number of bytes used by the process during
the transfer.

[h2parallel-mem]

Downloads 100 files each in 100 parallel transfers, each getting a 500MB file.
Using HTTP/2 over HTTPS from an Apache httpd running on localhost. This
measures the maximum RSS size in number of bytes used by the process during
the transfer.

[h3parallel-mem]

Downloads 100 files each in 100 parallel transfers, each getting a 500MB file.
Using HTTP/3 over HTTPS from a Caddy server running on localhost. This
measures the maximum RSS size in number of bytes used by the process during
the transfer.

[h1parallel-upload-speed]

Uploads 100 files each in 50 parallel transfers, each uploading a 500MB file.
Using HTTP/1.1 over HTTPS to an Apache httpd running on localhost. This
measures the total throughput in number of bytes per second.

[h2parallel-upload-speed]

Uploads 100 files each in 50 parallel transfers, each uploading a 500MB file.
Using HTTP/2 over HTTPS to an Apache httpd running on localhost. This measures
the total throughput in number of bytes per second.

[h3parallel-upload-speed]

Uploads 100 files each in 50 parallel transfers, each uploading a 500MB file.
Using HTTP/3 over HTTPS to an Apache httpd (via a httpx proxy) running on
localhost. This measures the total throughput in number of bytes per second.

[h1parallel-upload-mem]

Uploads 100 files each in 50 parallel transfers, each uploading a 500MB file.
Using HTTP/1.1 over HTTPS to an Apache httpd running on localhost. This
measures the maximum RSS size in number of bytes used by the process during
the transfer.

[h2parallel-upload-mem]

Uploads 100 files each in 50 parallel transfers, each uploading a 500MB file.
Using HTTP/2 over HTTPS to an Apache httpd running on localhost. This measures
the maximum RSS size in number of bytes used by the process during the
transfer.

[h3parallel-upload-mem]

Uploads 100 files each in 50 parallel transfers, each uploading a 500MB file.
Using HTTP/3 over HTTPS to an Apache httpd (via a httpx proxy) running on
localhost. This measures the maximum RSS size in number of bytes used by the
process during the transfer.

[h1-requests]

Downloads 100,000 small files (10K) using 40 parallel transfers over HTTP/1.1
HTTPS from an Apache httpd running on localhost. Measures how many such
requests per second it manages to perform.

[h2-requests]

Downloads 100,000 small files (10K) using 40 parallel transfers over HTTP/2
HTTPS from an Apache httpd running on localhost. Measures how many such
requests per second it manages to perform.

[h3-requests]

Downloads 100,000 small files (10K) using 40 parallel transfers over HTTP/3
HTTPS from a Caddy server running on localhost. Measures how many such
requests per second it manages to perform.

[h1-req-mem]

Downloads 100,000 small files (10K) using 40 parallel transfers over HTTP/1.1
HTTPS from an Apache httpd running on localhost. Measures the maximum RSS size
in number of bytes used by the process during the transfer.

[h2-req-mem]

Downloads 100,000 small files (10K) using 40 parallel transfers over HTTP/2
HTTPS from an Apache httpd running on localhost. Measures the maximum RSS size
in number of bytes used by the process during the transfer.

[h3-req-mem]

Downloads 100,000 small files (10K) using 40 parallel transfers over HTTP/3
HTTPS from a Caddy server running on localhost. Measures the maximum RSS size
in number of bytes used by the process during the transfer.

[easy-handle]

Uses the 'pahole' tool to extract the object size of the Curl_easy struct
(counted in number of bytes) from the build. One of these structs is allocated
as a handle for each libcurl transfer. The exact size of this struct depends
on architecture and build options.

[multi-handle]

Uses the 'pahole' tool to extract the object size of the Curl_multi struct
(counted in number of bytes) from the build. One of these structs is allocated
for each multi handle, and it may hold multiple concurrent transfers. The exact
size of this struct depends on architecture and build options.

[connectdata]

Uses the 'pahole' tool to extract the object size of the connectdata struct
(counted in number of bytes) from the build. One of these structs is allocated
for every concurrent connection libcurl holds. The exact size of this struct
depends on architecture and build options.

[h1rate-cpu]

Downloads 20 files in 20 parallel transfers over HTTPS using HTTP/1, each file
is 100MB. The transfers are limited to download at 5000KB/sec. This measures
the CPU% used for the transfer and it should be as low as possible.

[h1rate-speed]

Downloads 20 files in 20 parallel transfers over HTTPS using HTTP/1, each file
is 100MB. The transfers are limited to download at 5000KB/sec. The result
should be as exact to 5000KB/sec as possible. 5120000 bytes/second.

[b64enc]

This base64 encodes a 256-byte buffer holding the octet corresponding to its
index, 10 million times. The result is the average time in nanoseconds the
encode function takes.

[b64dec]

This test base64 decodes a buffer into a 256-byte buffer holding the octet
corresponding to its index. 10 million times. The result is the average time
in nanoseconds the decode function takes.

[snprintf]

Invokes a decently complicated curl_msnprintf() call ten million times and
evaluates the average time in nanoseconds the call took.

[urlparser]

This test has a list of 500+ different URLs. It parses each URL seven times
using different URL parser options. It then repeats it all 2500 times,
for a total of 10,097,500 URL parser invocations. The result is the average time in
nanoseconds the URL parsing function took across all invocations.

[urlencode]

URL encodes a 256-byte buffer holding the octet corresponding to its index.
2.5 million times. The result is the average time in nanoseconds the
encode function takes.

[urldecode]

URL descode an encoded string that decodes into a 256-byte buffer holding the
octet corresponding to its index. 2.5 million times. The result is the average
time in nanoseconds the decode function takes.

[maprintf]

This test repeatedly formats a request header block with `curl_maprintf()`,
which allocates the result, and measures the time per call. It exercises the
allocating output path and a `curl_off_t` conversion.

[simplef]

This test repeatedly formats a commonly used simple message with
`curl_msnprintf()`: literal text plus `%s`, a `size_t` and a `curl_off_t`,
with no width or precision. Where `snprintf` measures an elaborate format,
this measures the common one.

[dateparser]

This test has a list of 180+ different strings holding specific timestamps.
They include both valid and invalid dates. The test parses each such timestamp
100,000 times each. The result is the average time in nanoseconds the date
parser function curl_getdate() took across all invocations.

[numparser]

This test has a list of 140+ different octal, decimal and hexadecimal numbers
in strings. They include both valid and invalid numbers. The test parses each
such number 500,000 times each. The result is the average time in nanoseconds
the parser functions took across all invocations.

[build]

This measures the time used for the configure + make sequence when building
curl for the performance tests. Disabled shared build, unity with
optimization.