Skip to content

Latest commit

 

History

History
104 lines (76 loc) · 3.87 KB

7.0-Upgrade.md

File metadata and controls

104 lines (76 loc) · 3.87 KB

Welcome to Sidekiq 7.0!

Sidekiq 7.0 contains major new features and some breaking changes which streamline proper operation of Sidekiq. Please read these notes carefully.

What's New

Job Metrics

Sidekiq 7.0 adds a new "Metrics" tab in the Web UI with high-resolution data on job execution times along with the ability to mark deploy times. This allows you to monitor job execution times minute by minute and see when a deployment causes a performance regression. See the Metrics wiki page for details.

Embedding

Embedding is a new way to run Sidekiq. Previously, you could only run Sidekiq by starting a new process with bundle exec sidekiq. Now you can embed Sidekiq within another process with just a few lines of Ruby code. See the Embedding wiki page for details.

Capsules

Sidekiq 7.0 allows you to define "capsules" which execute jobs from queues. The default capsule spins up 5 Threads to fetch jobs from the default queue. You can change these values and/or define your own separate Capsules if you wish to throttle execution from a given queue. For instance, here's how to define a single-threaded capsule for thread-unsafe jobs:

Sidekiq.configure_server do |config|
  # edits the default capsule
  config.queues = %w[critical default low]
  config.concurrency = 5

  # define a new capsule which processes jobs from the `unsafe` queue one at a time
  config.capsule("unsafe") do |cap|
    cap.concurrency = 1
    cap.queues = %w[unsafe]
  end
end

This Sidekiq instance will have 6 threads executing jobs.

Note that Sidekiq's default concurrency has been reduced from 10 to 5. This matches the Rails default concurrency and database pool size. Use RAILS_MAX_THREADS=10 bundle exec sidekiq to adjust Sidekiq's concurrency and the Rails DB pool size:

# config/database.yml
default: &default
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>

Remember that your usable concurrency is limited by Ruby's GVL. If you increase your concurrency, you should be monitoring CPU usage to ensure you aren't saturating those CPUs.

Strict Arguments

Sidekiq's strict_args! mode was introduced in v6.4.0 and warned users for every job whose arguments were not strict JSON. In 7.0, this verification raises an exception by default. You can opt out of the check with Sidekiq.strict_args!(false) or just log a warning with Sidekiq.strict_args!(:warn).

redis-client

The redis-client gem is a new Rubygem which uses the RESP3 protocol found in Redis 6.0+. Sidekiq 6.5 introduced beta support for the redis-client gem while defaulting to using the redis gem. Sidekiq 7.0 completes this transition and no longer uses the redis gem internally. Your app can still continue to use redis. If you use Sidekiq.redis to access Redis connections, that API is now exposing a connection based on redis-client.

redis-namespace

Support for redis-namespace has been removed. I have advised against its usage for many years now. One option is to use Redis's numbered databases instead.

API Refactoring

Many APIs were tweaked or broken in this major release. If you see any breakage during your upgrade, check out our 7.0 API Migration guide.

Version Support

  • Redis 6.2+ is now required
  • Ruby 2.7+ is now required
  • Rails 6.0+ is now supported

Support is only guaranteed for the current and previous major versions. With the release of Sidekiq 7, Sidekiq 5.x is no longer supported.

Upgrade

As always, please upgrade Sidekiq one major version at a time. If you are already running Sidekiq 6.x, then:

  • Upgrade to the latest Sidekiq 6.x.
gem 'sidekiq', '< 7'
  • Fix any deprecation warnings you see.
  • Upgrade to 7.x.
gem 'sidekiq', '< 8'