INT-129: support rate-limit strategies #47
Merged
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
rupa
force-pushed
the
rate-limiting-strategies
branch
from
3c47b12
to
35d9432
Compare
The existing rate limit handling is based on handling an exception when
we get a 429 response. We add some strategies that base behavior on the headers
from every response, without waiting for a 429. These are the same strategies
we have in the Go-SDK:
Adds two strategies:
* solo - sleep longer the closer we are to running out of tokens
* concurrent - needs a "parallelism" argument, accounts for the other workers
in determining how long to sleep. doesn't kick in until tokens remaining
is <= parallelism
Strategy is set and determined by config variables, the default (for now) is
"no strategy", i.e. preserves current behavior.
Added tests for resource: exercises transports and rate-limiting
There is an example of using rate-limiting strategies
I added support for these via config, and the different "transports". There is
some refactoring of transport internals to fix bugs, support various py
versions, and for ease of testing. Functionality should not be affected
in normal use:
* basic transport
* pull ssl workaround for url openers into a method
* replace references to `resp.hdrs` with a _get_headers function that
should be consistent across py versions.
* try/except around body.decode to handle str/bytes response from different
py versions
* twisted transport
* move ResourceException into class init. having it at top-level makes it
tough to use e.g. py3.3 (without twisted).
Bonus:
* Update README about supported python versions and what we run CI against.
turns out the "py33" env in tox.ini is actually 3.6
rupa
force-pushed
the
rate-limiting-strategies
branch
from
7f0d69b
to
1ffb832
Compare
rupa
changed the title
|
I ended up amending each transport to handle rate limiting, originally I tried to do it all in the BaseResource, but twisted is the "odd one out" and it felt more wrong to handle all-but-one in the resource or thread headers up into higher-level code, than to just have a bit of handling in each transport. Due to this, the logic for selecting/setting up the rate limit strategy ended up fitting best in the Config class, which kept the changes to transports fairly small. |
mburtless
approved these changes
Jan 8, 2020
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.
force pushed, see commit message