Hacker News Reader

Comment by wc- | Hacker News Reader

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).

View on HN

We 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.. :)

Can 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!

I'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.

IIRC, Celery uses token bucket algorithm for rate limiting. SHARQ uses the leaky bucket algorithm (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), 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.

Reply on news.ycombinator.com