dfc7e35b11
This commit removes the need to poll a global array for received signals every second by introducing an internal pipe(2). The writing end of the pipe is being used in the block trapping the signals. Whenever a signal is received, the signal's name gets written to the pipe. Instead of polling for received signals, the code now uses select(2) to check whether the internal pipe has been written to and can be read from. select(2) is blocking until one of the passed file descriptors is ready for reading/writing or has an exception, which means the code does not need to use `sleep 1` anymore. So when a signal is sent to the sidekiq process, the signal name gets written to the internal pipe, select(2) returns and the process can react according to the received signal. After handling a signal, select(2) gets called again and blocks until receiving another signal. |
||
---|---|---|
bin | ||
examples | ||
lib | ||
myapp | ||
test | ||
web | ||
.gitignore | ||
.travis.yml | ||
Changes.md | ||
COMM-LICENSE | ||
config.ru | ||
Gemfile | ||
LICENSE | ||
Rakefile | ||
README.md | ||
sidekiq.gemspec |
Sidekiq
Simple, efficient message processing for Ruby.
Sidekiq uses threads to handle many messages at the same time in the same process. It does not require Rails but will integrate tightly with Rails 3 to make background message processing dead simple.
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.
At the same time, Sidekiq uses multithreading so it is 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 efficiency and how I was able to shrink a Carbon Five client's resque processing farm from 9 machines to 1 machine.
Requirements
I test on Ruby 1.9.3 and JRuby 1.6.x in 1.9 mode. Other versions/VMs are untested but I will do my best to support them. Ruby 1.8 is not supported.
Redis 2.0 or greater is required.
Installation
gem install sidekiq
Getting Started
See the sidekiq home page for the simple 4-step process. You can watch Railscast #366 to see Sidekiq in action.
More Information
Please see the sidekiq wiki for more information. #sidekiq on irc.freenode.net is dedicated to this project, but bug reports or feature requests suggestions should still go through issues on Github.
There's also a mailing list via Librelist that you can subscribe to by sending an email to sidekiq@librelist.org with a greeting in the body. To unsubscribe, send an email to sidekiq-unsubscribe@librelist.org and that's it! Once archiving begins, you'll be able to visit the archives to see past threads.
Problems?
Please do not directly email any Sidekiq committers with questions or problems. A community is best served when discussions are held in public.
If you have a problem, please review the FAQ and Troubleshooting wiki pages. Searching the issues for your problem is also a good idea. If that doesn't help, feel free to email the Sidekiq mailing list or open a new issue. The mailing list is the preferred place to ask questions on usage. If you are encountering what you think is a bug, please open an issue.
License
Please see LICENSE for licensing details.
Author
Mike Perham, @mperham, http://mikeperham.com