rate_throttle_client 0.1.1 → 0.1.2
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/.circleci/config.yml +3 -3
- data/.github/workflows/check_changelog.yml +3 -1
- data/CHANGELOG.md +4 -0
- data/README.md +10 -0
- data/lib/rate_throttle_client.rb +1 -1
- data/lib/rate_throttle_client/version.rb +1 -1
- metadata +2 -2
checksums.yaml
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
SHA256:
|
|
3
|
-
metadata.gz:
|
|
4
|
-
data.tar.gz:
|
|
3
|
+
metadata.gz: 15964fd933fe8aa520465526cc04d6c123015e98bbcacf0b698ccb9b1257ab43
|
|
4
|
+
data.tar.gz: 1384027636932998bf4dc958b4d69bc2255672357e15e222fce24537b25be216
|
|
5
5
|
SHA512:
|
|
6
|
-
metadata.gz:
|
|
7
|
-
data.tar.gz:
|
|
6
|
+
metadata.gz: e693cd14863ea2e2cfd331744c64caeade1ce30def4e2e843a46327e4ef29b32db9768fb0cff38c0cc7fab9861e12ef4e0f7bfd1bfb81e4d8e6c587cae073a1c
|
|
7
|
+
data.tar.gz: 94eeb769605a1da271a84ca4576c582edee21e25a4bb8f70db208d78b2cf47cf621f07ed30c9e63e4366a99cea2ee5dcbbcc3f667678d03bdfc71869f436add9
|
data/.circleci/config.yml
CHANGED
|
@@ -29,7 +29,7 @@ references:
|
|
|
29
29
|
jobs:
|
|
30
30
|
"ruby-2.2":
|
|
31
31
|
docker:
|
|
32
|
-
- image: circleci/ruby:2.
|
|
32
|
+
- image: circleci/ruby:2.2
|
|
33
33
|
steps:
|
|
34
34
|
- checkout
|
|
35
35
|
- <<: *imagick
|
|
@@ -38,7 +38,7 @@ jobs:
|
|
|
38
38
|
- <<: *unit
|
|
39
39
|
"ruby-2.3":
|
|
40
40
|
docker:
|
|
41
|
-
- image: circleci/ruby:2.
|
|
41
|
+
- image: circleci/ruby:2.3
|
|
42
42
|
steps:
|
|
43
43
|
- checkout
|
|
44
44
|
- <<: *imagick
|
|
@@ -47,7 +47,7 @@ jobs:
|
|
|
47
47
|
- <<: *unit
|
|
48
48
|
"ruby-2.4":
|
|
49
49
|
docker:
|
|
50
|
-
- image: circleci/ruby:2.
|
|
50
|
+
- image: circleci/ruby:2.4
|
|
51
51
|
steps:
|
|
52
52
|
- checkout
|
|
53
53
|
- <<: *imagick
|
data/CHANGELOG.md
CHANGED
data/README.md
CHANGED
|
@@ -68,6 +68,16 @@ To choose, you need to understand what makes a "good" throttling strategy, and t
|
|
|
68
68
|
|
|
69
69
|
The only strategy that handles all these scenarios well is currently: `RateThrottleClient::ExponentialIncreaseProportionalRemainingDecrease` against a [GCRA rate limit strategy, such as the one implemented by the Heroku API]().
|
|
70
70
|
|
|
71
|
+
## Pretty Chart
|
|
72
|
+
|
|
73
|
+
Here's a simulated run with the `ExponentialIncreaseProportionalRemainingDecrease` strategy with 10 clients (2 processes, 5 threads each) against a GCRA server for half an hour:
|
|
74
|
+
|
|
75
|
+
|
|
76
|
+
|
|
77
|
+
> A calculated optimal sleep time average for the system would be 8 seconds per client (arrival rate of new request capacity is 0.8 seconds, and there are 10 clients), this strategy oscilates around that value without needing complete information about the distributed system.
|
|
78
|
+
|
|
79
|
+
To generate a chart for all strategies run `rake bench`.
|
|
80
|
+
|
|
71
81
|
## Benchmarks
|
|
72
82
|
|
|
73
83
|
These benchmarks are generated by running `rake bench` against the simulated "[GCRA](https://brandur.org/rate-limiting)" rate limiting server.
|
data/lib/rate_throttle_client.rb
CHANGED
|
@@ -8,7 +8,7 @@ module RateThrottleClient
|
|
|
8
8
|
class << self
|
|
9
9
|
attr_accessor :multiplier, :min_sleep, :max_limit, :log_block
|
|
10
10
|
end
|
|
11
|
-
self.log_block = ->(info) {
|
|
11
|
+
self.log_block = ->(info) { warn "RateThrottleClient: sleep_for=#{info.sleep_for}" }
|
|
12
12
|
self.max_limit = 4500.to_f
|
|
13
13
|
self.min_sleep = 3600/max_limit
|
|
14
14
|
self.multiplier = 1.2
|
metadata
CHANGED
|
@@ -1,14 +1,14 @@
|
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
|
2
2
|
name: rate_throttle_client
|
|
3
3
|
version: !ruby/object:Gem::Version
|
|
4
|
-
version: 0.1.
|
|
4
|
+
version: 0.1.2
|
|
5
5
|
platform: ruby
|
|
6
6
|
authors:
|
|
7
7
|
- schneems
|
|
8
8
|
autorequire:
|
|
9
9
|
bindir: exe
|
|
10
10
|
cert_chain: []
|
|
11
|
-
date: 2020-
|
|
11
|
+
date: 2020-05-08 00:00:00.000000000 Z
|
|
12
12
|
dependencies:
|
|
13
13
|
- !ruby/object:Gem::Dependency
|
|
14
14
|
name: wait_for_it
|