4 ms·
Looks pretty cool, looking forward to playing around with it. How does this compare to celery w/ rate limiting of individual tasks? Celery can be pretty daunt
by wc- 12y ago
Looks pretty cool, looking forward to playing around with it.
How does this compare to celery w/ rate limiting of individual tasks? Celery can be pretty daunting (heavyweight perhaps?) sometimes, having a simpler alternative could be useful. However, I wonder if by the time you need rate limiting of queues, you will probably need additional "heavy" features as well.
I'd love to see a deeper comparison of sharq's usage of redis vs celery's. For example, are there any performance gains by using sharq's lua commands or schemas vs celery's?
There are a few typo's in the features section btw (minmal, seriazlied).
- ohmygeek 12y agoWe had evaluated Celery for our use case. There were a few things it couldn't do such as create queues dynamically with per queue rate limit. We chose Lua because the queue operations involve modifying more than one Redis data structure and this had to be atomic. We'll be adding more details on why we built this and how it compares with Celery.. :)
- SEJeff 12y agoCan you please not do one thing Ask (celery author) constantly does? He breaks the celery API to a ridiculous degree between point releases. I've used celery for 5+ years and constantly have to hard fix the version I use in a requirements.txt or whatnot because the most seemingly minor point release results in broken tasks and a different api. Use semver or something sane to not make your users angry. Pretty please!
- armon 12y agoI'm also curious how this compares to Celery with rate limiting. One advantage of Celery is that you can use an AMQP broker which is probably better suited than Redis if you care about durability and at-least-once delivery.
- ohmygeek 12y agoIIRC, Celery uses token bucket algorithm for rate limiting. SHARQ uses the leaky bucket algorithm (http://en.wikipedia.org/wiki/Leaky_bucket#The_Leaky_Bucket_Algorithm_as_a_Queue http://en.wikipedia.org/wiki/Leaky_bucket#The_Leaky_Bucket_A...). The advantage of leaky bucket is that, it enforces a constant flow of jobs out of SHARQ regardless of the spike in enqueue rate. Even though SHARQ uses Redis, it has been designed in a way to support at-least-once delivery. If you see the getting started section (http://sharq.io/docs/gettingstarted.html http://sharq.io/docs/gettingstarted.html), there is a Finish API which would acknowledge every job dequeued. SHARQ ensures that a job will be requeued back into the queue if it does not receive a Finish request.