• Stars
    star
    233
  • Rank 172,230 (Top 4 %)
  • Language
    Ruby
  • License
    MIT License
  • Created almost 12 years ago
  • Updated 11 months ago

Reviews

There are no reviews yet. Be the first to send feedback to the community and the maintainers!

Repository Details

Sidekiq middleware that adds the ability to rate limit job execution.

Sidekiq::Throttler

Build Status Dependency Status Gem Version

Sidekiq::Throttler is a middleware for Sidekiq that adds the ability to rate limit job execution on a per-worker basis.

Compatibility

Sidekiq::Throttler supports Sidekiq versions 2 and 3 and is actively tested against Ruby versions 2.0.0, 2.1, and 2.2.

Installation

Add this line to your application's Gemfile:

gem 'sidekiq-throttler'

And then execute:

$ bundle

Or install it yourself as:

$ gem install sidekiq-throttler

Configuration

In a Rails initializer or wherever you've configured Sidekiq, add Sidekiq::Throttler to your server middleware:

Sidekiq.configure_server do |config|
  config.server_middleware do |chain|
    chain.add Sidekiq::Throttler
  end
end

Sidekiq::Throttler defaults to in-memory storage of job execution times. If you have multiple worker processes, or frequently restart your processes, this will be unreliable. Instead, specify the :redis storage option:

Sidekiq.configure_server do |config|
  config.server_middleware do |chain|
    chain.add Sidekiq::Throttler, storage: :redis
  end
end

Basic Usage

In a worker, specify a threshold (maximum jobs) and period for throttling:

class MyWorker
  include Sidekiq::Worker

  sidekiq_options throttle: { threshold: 50, period: 1.hour }

  def perform(user_id)
    # Do some heavy API interactions.
  end
end

In the above example, when the number of executed jobs for the worker exceeds 50 in an hour, remaining jobs will be delayed.

Advanced Usage

Custom Keys

By default, each worker has its own key for throttling. For example:

class FooWorker
  include Sidekiq::Worker

  sidekiq_options throttle: { threshold: 50, period: 1.hour }

  # ...
end

class BarWorker
  include Sidekiq::Worker

  sidekiq_options throttle: { threshold: 50, period: 1.hour }

  # ...
end

Even though FooWorker and BarWorker use the same throttle options, they are treated as different groups. To have multiple workers with shared throttling, the :key options can be used:

sidekiq_options throttle: { threshold: 50, period: 1.hour, key: 'foobar' }

Any jobs using the same key, regardless of the worker will be tracked under the same conditions.

Dynamic Throttling

Each option (:threshold, :period, and :key) accepts a static value but can also accept a Proc that's called each time a job is processed.

Dynamic Keys

If throttling is per-user, for example, you can specify a Proc for key which accepts the arguments passed to your worker's perform method:

sidekiq_options throttle: { threshold: 20, period: 1.day, key: ->(user_id){ user_id } }

In the above example, jobs are throttled for each user when they exceed 20 in a day.

Dynamic Thresholds

Thresholds can be configured based on the arguments passed to your worker's perform method, similar to how the key option works:

sidekiq_options throttle: { threshold: ->(user_id, rate_limit) { rate_limit }, period: 1.hour, key: ->(user_id, rate_limit){ user_id } }

In the above example, jobs are throttled for each user when they exceed the rate limit provided in the message. This is useful in cases where each user may have a different rate limit (ex: interacting with external APIs)

Dynamic Periods

In this contrived example, our worker is limited to 9 thousand jobs every 10 minutes. However, on Tuesdays limit jobs to 9 thousand every 15 minutes:

sidekiq_options throttle: { threshold: 9000, period: ->{ Date.today.tuesday? ? 15.minutes : 10.minutes } }

Contributing

  1. Fork it
  2. Create your feature branch (git checkout -b my-new-feature)
  3. Commit your changes (git commit -am 'Add some feature')
  4. Push to the branch (git push origin my-new-feature)
  5. Create new Pull Request

License

MIT Licensed. See LICENSE.txt for details.

More Repositories

1

kohana-partials

Partial rendering for Kohana 3.x
PHP
19
star
2

pick

Install and switch between multiple miners (cgminer, sgminer, and bfgminer) and versions in a manner similar to rbenv.
Shell
15
star
3

kollapse

Asset packaging for Kohana 3
PHP
11
star
4

kohana-airbrake

Exception handling and error notifications through Airbrake.
PHP
8
star
5

respond-rails

Ruby
7
star
6

miner-install

Installs CGMiner, BFGMiner, or SGMiner.
Shell
6
star
7

phaker

A PHP port of Faker for random generation of data such as, names, addresses, and phone numbers.
PHP
5
star
8

vagrant-lnmp-cookbooks

Chef cookbooks for Vagrant supporting Linux + Nginx + MySQL + PHP-FPM
Ruby
4
star
9

chef-varnish

Varnish cookbook forked from opscode/cookbooks
Ruby
4
star
10

sublime-packages

My Sublime Text packages and configurations
Python
2
star
11

dotfiles-old

Various configurations, shell scripts, etc. shared across my computers.
Shell
2
star
12

kohana-protect-from-forgery

Kohana 3.x module for drop-in protection from Cross-Site Request Forgery
PHP
2
star
13

catalyst

Build script for patching AMD Catalyst and producing installable debs. Runs in a Vagrant box to ease development on a Mac.
Shell
1
star
14

rumble-bootstrap

Bootstrap a Linode server with your own mini-Heroku for Rails Rumble 2013
Shell
1
star
15

koi

Painless payment processing for Kohana. Based on Shopify's Active Merchant.
PHP
1
star
16

specter

Specter stubs a subset of the cgminer client protocol. It allows you to test your programs against a dummy server.
Ruby
1
star
17

vimfiles

My personal ~/.vim directory
Vim Script
1
star
18

expedition

Expedition is a Ruby implementation of the cgminer client protocol. It allows you to write programs that interact with cgminer and cgminer-compatible software.
Ruby
1
star