Live data from Hacker News

Celery in production: Three more years of fixing bugs

ayushshanker.com

41–50 of 63 posts

Re: Celery in production: Three more years of fixing bugs

#41
I would put celery in that class of software that's good enough to be useful, but enough trouble that you'll never be truly happy with it.

We got a lot of mileage out of it (in a past life) before finally moving our job scheduling to a custom solution built on RQ. Celery caused more than a few headaches -- which is why we ditched it -- but its flexibility probably helped us scale up the service to begin with...

Re: Celery in production: Three more years of fixing bugs

#43

Can any explain why we need task queue? It is unique to Python because of it lack of real threading?

We have used it to run different CPU bound tasks on worker machines (to not run them on the app server).

For example imagine you want to receive a file from the user and extract data from it.

Using such system also allowed us to horizontally scale by adding more worker machines.

All this, of course, depends on the tasks you want to schedule.

Re: Celery in production: Three more years of fixing bugs

#44
post #40

Earlier quoted context omitted.

What would you recommend instead?

Beanstalkd? These comments say better than I can why I like it https://news.ycombinator.com/item?id=27483167 https://news.ycombinator.com/item?id=24714198

Celery is not a broker daemon, it's an abstraction for them. You can use it with various brokers and some kv databases such as redis.

And yes, celery also supports beanstalk, so it's clearly not an alternative to it

http://docs.celeryproject.org/en/latest/getting-started/brok...

Re: Celery in production: Three more years of fixing bugs

#45
post #3

I ran Celery in many projects in production over the past 10 years; I would not recommend it. It is mostly a constant fight even though it is the first thing most people grab when they have a Django stack.

What would you recommend instead?

We have transitioned over to Dramatiq.

It has its own set of problems (mostly from starting at the set of "we will remove all of Celery features" and then going from there), in particular its logging policies are extremely frustrating and we have had to work around them. But the code is so simple in general that we get good compensation for that.

I personally would have liked to use dq instead but that's mostly an aesthetics thing.

Re: Celery in production: Three more years of fixing bugs

#47
post #3

I ran Celery in many projects in production over the past 10 years; I would not recommend it. It is mostly a constant fight even though it is the first thing most people grab when they have a Django stack.

What would you recommend instead?

For under 1000 messages per second, PostgreSQL is great at queues.

Re: Celery in production: Three more years of fixing bugs

#48
post #3

I ran Celery in many projects in production over the past 10 years; I would not recommend it. It is mostly a constant fight even though it is the first thing most people grab when they have a Django stack.

What would you recommend instead?

Currently exploring using arq, a successor to rq for my next project.

Re: Celery in production: Three more years of fixing bugs

#49
post #15

Earlier quoted context omitted.

I've been running four separate installs of Celery since 2014 or so processing about 10-20 million jobs a day, using reddit as a broker, and with about 100 worker instances per install. It just works, but I don't use Celery results or any esoteric features.

Reddit :)

Posts to a subreddit as things in the queue, comments for results and feedback like progress percentages, up and down votes for priorities...

Re: Celery in production: Three more years of fixing bugs

#50
post #42

Earlier quoted context omitted.

Did we just witness a Freudian slip? :)

Or overzealous phone auto correct. Redis used to auto correct to Reddit on an old android device of mine heh.

I can't stop giggling. ;)
Post reply on HN