2. What is Sidekiq?
●
Async job manager
●
Released by Mike Perham in January 2012
●
Developed for theclymb.com
●
Drop-in replacement for Resque (almost)
●
Uses Celluloid gem for concurrency
3. Async challenges
●
Adds complexity (redis, sidekiq daemon)
●
Workers must be thread-safe and idempotent
●
Timing-related bugs are difficult to reproduce
4. Thread-safety
●
●
●
●
Uses all shared variables in an atomic way,
unless each is allocated to a specific instance
of the worker
Does not call non-thread-safe methods
Does not use APIs or database in a non-atomic
way
The G{I,V}L does NOT make Ruby thread-safe
5. Idempotency
●
●
An idempotent operation is one that has no
additional effect if it is called more than once
with the same input parameters
Sidekiq will retry jobs if there is an error
6. Why Sidekiq?
●
●
Sidekiq is faster, uses fewer resources, and is
well-supported
TheClymb claims 100% uptime for sidekiq*
Name
Database
delayed_job
SQL
Resque
redis
Sidekiq
redis
Threads
1
1
many
* but they restart sidekiq daemons every day
Resque forks a complete copy of parent
Sidekiq spawns threads, uses actor model
Shared mutable state == risky
Rebuild context in the worker; assume nothing
Constants aren't!
Pay special attention to anything global
ENV
Constants
Retry interval and count are configurable
For real work, people report that one sidekiq daemon can do the work of 8-25 resque workers in far less memory
Use ID isntead of data for 2 reasons:
Less data to marshall/unmarshall
Get to test whether it still exists (and needs to be sent) when the job is processed