1
0
Fork 0
mirror of https://github.com/mperham/sidekiq.git synced 2022-11-09 13:52:34 -05:00

Merge pull request #91 from seamusabshere/patch-1

Clarify that Sidekiq uses multithreading instead of forking
This commit is contained in:
Mike Perham 2012-03-26 07:56:15 -07:00
commit 2e9e3a5064

View file

@ -3,14 +3,12 @@ Sidekiq
Simple, efficient message processing for Ruby.
Sidekiq aims to be compatible with Resque. It uses the exact same
Sidekiq is compatible with Resque. It uses the exact same
message format as Resque so it can integrate into an existing Resque processing farm.
You can have Sidekiq and Resque run side-by-side at the same time and
use the Resque client to enqueue messages in Redis to be processed by Sidekiq.
Sidekiq is different from Resque in how it processes messages: it
processes many messages concurrently per process. Resque only processes
one message at a time per process so it is far less memory efficient.
At the same time, Sidekiq uses multithreading so it much more memory efficient than Resque (which forks a new process for every job).
You'll find that you might need 50 200MB resque processes to peg your CPU
whereas one 300MB Sidekiq process will peg the same CPU and perform the
same amount of work. Please see [my blog post on Resque's memory
@ -18,6 +16,8 @@ efficiency](http://blog.carbonfive.com/2011/09/16/improving-resques-memory-effic
and how I was able to shrink a Carbon Five client's resque processing farm
from 9 machines to 1 machine.
In sum, if your jobs are well-behaved and threadsafe, Sidekiq is probably a good replacement for Resque. If your jobs are not thread-safe or they leak memory, you may want to continue using Resque, because its forking model gives you more protection.
Requirements
-----------------