fix(bin/bench): on upload, do not also request large download #2546
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The `neqo-bin` Download benchmark has the client do a single HTTP GET to the server, requesting the number of bytes to download encoded in the URL path, i.e. `http://[::1]:12345/104857600`. The `neqo-bin` Upload benchmark has the client do a single HTTP POST to the server, sending `104857600` random bytes along with it. That said, previously it would also request the same amount of bytes to download from the server. This explains the Download / Upload difference seen in mozilla#2538. Fixed in this commit.
|
Oh, good catch. |
|
Can we keep a bidirectional transfer as part of the benches? |
For sure. I will do a follow-up pull request. Sounds good? |
Failed Interop TestsQUIC Interop Runner, client vs. server neqo-latest as client
neqo-latest as server
All resultsSucceeded Interop TestsQUIC Interop Runner, client vs. server neqo-latest as client
neqo-latest as server
Unsupported Interop TestsQUIC Interop Runner, client vs. server neqo-latest as client
neqo-latest as server
|
Benchmark resultsPerformance differences relative to e72ae0c. 1-conn/1-100mb-resp/mtu-1504 (aka. Download)/client: Change within noise threshold. time: [717.32 ms 722.63 ms 727.96 ms]
thrpt: [137.37 MiB/s 138.38 MiB/s 139.41 MiB/s]
change:
time: [+0.5586% +1.6106% +2.6568%] (p = 0.00 < 0.05)
thrpt: [-2.5880% -1.5851% -0.5555%]
1-conn/10_000-parallel-1b-resp/mtu-1504 (aka. RPS)/client: No change in performance detected. time: [348.55 ms 350.05 ms 351.54 ms]
thrpt: [28.447 Kelem/s 28.567 Kelem/s 28.690 Kelem/s]
change:
time: [-0.8823% -0.2353% +0.4030%] (p = 0.49 > 0.05)
thrpt: [-0.4014% +0.2359% +0.8902%]
1-conn/1-1b-resp/mtu-1504 (aka. HPS)/client: 💚 Performance has improved. time: [24.890 ms 25.033 ms 25.181 ms]
thrpt: [39.712 elem/s 39.947 elem/s 40.176 elem/s]
change:
time: [-4.1887% -3.3991% -2.5881%] (p = 0.00 < 0.05)
thrpt: [+2.6568% +3.5187% +4.3718%]
1-conn/1-100mb-req/mtu-1504 (aka. Upload)/client: 💚 Performance has improved. time: [1.9373 s 1.9589 s 1.9805 s]
thrpt: [50.493 MiB/s 51.050 MiB/s 51.617 MiB/s]
change:
time: [-17.554% -16.358% -15.154%] (p = 0.00 < 0.05)
thrpt: [+17.860% +19.557% +21.292%]
decode 4096 bytes, mask ff: No change in performance detected. time: [12.003 µs 12.044 µs 12.091 µs]
change: [+0.0555% +0.7942% +1.9294%] (p = 0.08 > 0.05)
decode 1048576 bytes, mask ff: No change in performance detected. time: [2.9475 ms 2.9551 ms 2.9645 ms]
change: [-0.5920% -0.1424% +0.3118%] (p = 0.54 > 0.05)
decode 4096 bytes, mask 7f: No change in performance detected. time: [20.018 µs 20.073 µs 20.131 µs]
change: [-0.0088% +0.6273% +1.5471%] (p = 0.10 > 0.05)
decode 1048576 bytes, mask 7f: No change in performance detected. time: [4.7949 ms 4.8065 ms 4.8198 ms]
change: [-0.3169% +0.0455% +0.4015%] (p = 0.80 > 0.05)
decode 4096 bytes, mask 3f: No change in performance detected. time: [6.3248 µs 6.3582 µs 6.3977 µs]
change: [-0.0435% +0.3699% +0.8187%] (p = 0.10 > 0.05)
decode 1048576 bytes, mask 3f: No change in performance detected. time: [2.1487 ms 2.1544 ms 2.1615 ms]
change: [-0.6239% -0.1589% +0.3046%] (p = 0.52 > 0.05)
1 streams of 1 bytes/multistream: No change in performance detected. time: [70.260 µs 71.309 µs 72.808 µs]
change: [-2.1571% +0.0676% +2.3125%] (p = 0.95 > 0.05)
1000 streams of 1 bytes/multistream: No change in performance detected. time: [25.333 ms 25.371 ms 25.409 ms]
change: [-0.2905% -0.0666% +0.1483%] (p = 0.55 > 0.05)
10000 streams of 1 bytes/multistream: No change in performance detected. time: [1.7053 s 1.7071 s 1.7091 s]
change: [-0.1856% -0.0296% +0.1280%] (p = 0.71 > 0.05)
1 streams of 1000 bytes/multistream: No change in performance detected. time: [71.748 µs 72.396 µs 73.503 µs]
change: [-0.9538% +0.0118% +1.5579%] (p = 0.98 > 0.05)
100 streams of 1000 bytes/multistream: No change in performance detected. time: [3.3864 ms 3.3932 ms 3.4003 ms]
change: [-0.2811% +0.0112% +0.3095%] (p = 0.93 > 0.05)
1000 streams of 1000 bytes/multistream: Change within noise threshold. time: [145.53 ms 145.61 ms 145.70 ms]
change: [-0.1769% -0.0965% -0.0212%] (p = 0.02 < 0.05)
coalesce_acked_from_zero 1+1 entries: No change in performance detected. time: [94.897 ns 95.250 ns 95.600 ns]
change: [-1.9455% -0.5878% +0.2478%] (p = 0.39 > 0.05)
coalesce_acked_from_zero 3+1 entries: No change in performance detected. time: [112.94 ns 113.22 ns 113.52 ns]
change: [-0.2997% -0.0435% +0.2345%] (p = 0.75 > 0.05)
coalesce_acked_from_zero 10+1 entries: No change in performance detected. time: [112.52 ns 112.93 ns 113.43 ns]
change: [-1.1281% -0.4127% +0.2555%] (p = 0.25 > 0.05)
coalesce_acked_from_zero 1000+1 entries: No change in performance detected. time: [94.266 ns 94.739 ns 95.261 ns]
change: [+0.0285% +2.9431% +7.9162%] (p = 0.16 > 0.05)
RxStreamOrderer::inbound_frame(): Change within noise threshold. time: [116.53 ms 116.58 ms 116.63 ms]
change: [-0.3771% -0.3150% -0.2495%] (p = 0.00 < 0.05)
SentPackets::take_ranges: No change in performance detected. time: [8.1537 µs 8.4174 µs 8.6544 µs]
change: [-5.3000% -1.4801% +2.4891%] (p = 0.43 > 0.05)
transfer/pacing-false/varying-seeds: Change within noise threshold. time: [36.067 ms 36.131 ms 36.194 ms]
change: [+2.0038% +2.2525% +2.4929%] (p = 0.00 < 0.05)
transfer/pacing-true/varying-seeds: Change within noise threshold. time: [35.914 ms 35.989 ms 36.064 ms]
change: [+0.5757% +0.8401% +1.1055%] (p = 0.00 < 0.05)
transfer/pacing-false/same-seed: Change within noise threshold. time: [35.423 ms 35.484 ms 35.543 ms]
change: [+0.2720% +0.5055% +0.7278%] (p = 0.00 < 0.05)
transfer/pacing-true/same-seed: Change within noise threshold. time: [35.889 ms 35.937 ms 35.987 ms]
change: [+0.3653% +0.5549% +0.7298%] (p = 0.00 < 0.05)
Client/server transfer resultsPerformance differences relative to e72ae0c. Transfer of 33554432 bytes over loopback, 30 runs. All unit-less numbers are in milliseconds.
|
|
I was wrong. Updated the PR description. Still worth merging.
|
|
Can we add separate options for upload and download size, so that the request URL contains the download size and the client just uploads/POSTs the upload size? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
neqo-binDownload benchmark has the client do a single HTTP GET to the server, requesting the number of bytes to download encoded in the URL path, i.e.http://[::1]:12345/104857600.The
neqo-binUpload benchmark has the client do a single HTTP POST to the server, sending104857600random bytes along with it. That said, previously it would also request the same amount of bytes to download from the server.This accidentally made it both an Upload and a Download benchmark.This explains the Download / Upload difference seen in #2538.While a bug, this does not fix #2538, given that the HTTP3 server would simply ignore the
/104857600URL path on receiving aPOST.neqo/neqo-bin/src/server/http3.rs
Lines 99 to 102 in e72ae0c
Anyways, still worth merging.
My mistake. Sorry for the trouble!