add: naive implementation of a minimum-throughput body with tests #1627
Conversation
|
A new generated diff is ready to view.
A new doc preview is ready to view. |
| // Will send slightly less that 1 byte per second because ASCII digits have a size | ||
| // of 1 byte and we sleep for 1 second after every digit we send. | ||
| tx.send(Ok(format!("{}", i))).await.expect("failed to send"); | ||
| async_sleep.sleep(Duration::from_secs(1)).await; |
There was a problem hiding this comment.
Ideally, we should be able to fake time keeping in the MinimumThroughputBody so that we don't need to sleep in tests. Essentially, be able to replace the source of Instant::now() inside of MinimumThroughputBody.
| let actual_bytes_per_second = | ||
| total_bytes_read as f64 / time_elapsed_since_first_poll.as_secs_f64(); |
There was a problem hiding this comment.
I think to be accurate for longer downloads, and to avoid consuming excess memory, you'll need to have a sliding window over the throughput_logs. It's probably as simple as popping the front of the vec until the first entry is no longer older than the configured duration (before doing this calculation).
Additionally, we probably shouldn't do this comparison at all unless the configured duration has elapsed already. Otherwise, there's a chance that a slow-to-start download would always result in failure since it would only have one data point.
| } | ||
| } | ||
|
|
||
| #[tokio::test] |
There was a problem hiding this comment.
I'm feeling mathy today, bear with me...
I think a good test to add may be a shrinking sine wave. Something like (abs(sin(x))+0.5) * max(0, (-0.05x+1)), which may require a little bit of tweaking.
With that function, it should start off happy despite some significant drop offs in speed periodically, but eventually (after 20 seconds or so) get to a point where it needs to timeout.
Another good test is a straight line going up starting at 1, something like x+1, just to make sure it doesn't break on slow starts.
And then, another good one would be a full minute of good throughput, then 0.5 seconds of zero throughput, followed by good throughput again.
|
Closing this until we pick up #1562 again. |
Motivation and Context
#1562
Description
Exactly what it says on the tin
Testing
tests are included
Checklist
CHANGELOG.next.tomlif I made changes to the smithy-rs codegen or runtime cratesCHANGELOG.next.tomlif I made changes to the AWS SDK, generated SDK code, or SDK runtime cratesBy submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.