Alternativen zu Celery...

[jens]

Boah... Ich hab die letzten Stunden und Tage damit verbracht, celery vernünftig zum laufen zu bekommen. Bzw. für die Tasks tests zu schreiben. Allein heute bin ich in einige Bugs gelaufen:

https://github.com/celery/celery/issues/5033
https://github.com/celery/celery/issues/5034
https://github.com/celery/celery/issues/5035

Die Bugs zu finden ist echt Zeitaufwendig und so langsam hab ich keinen bock mehr

Also, vielleicht einfach eine Alternative nutzten? Ich brauche eh nur eine Lösung für Django und von daher wäre eine Django-Admin-Integration auch toll. Bei Celery gibt es dafür zwar auch was seperates, aber:

https://github.com/celery/django-celery ... /issues/65
https://github.com/celery/django-celery ... /issues/61

Hab mal einen Blick auf https://djangopackages.org/grids/g/work ... ues-tasks/ geworfen.

Spontan sieht https://github.com/Koed00/django-q ganz nett aus...

Hat jemand Erfahrungen mit einer Alternative und kann berichten?!?

[DasIch]

Celery tut schon sehr viel, insofern stellt sich hier die Frage: Was tust du überhaupt?

Nächstgelegene Queue (in unserem Fall üblicherweise Nakadi) + Cronjob bringt einen erfahrungsgemäß schon sehr weit. SQS+Lambda ist auch nicht schlecht hat man aber natürlich AWS lock-in.

Wenn du wenige Events hast mit überschaubarer Frequenz, tut es eine Tabelle in Postgres statt der Queue auch. Bei vielen Events und dem starken Drang zu Postgres kommt man auch mit PGQ sehr weit.

[jens]

Also ich hab eigentlich nicht viele gleichzeitige Events. Alles überschaubar.

Bei https://github.com/Koed00/django-q fällt mir gleich mal auf, das im Bug Tracker viele unbeantwortete issues sind. Da fangen die Alarmglocken an zu schellen...

Vielleicht ist es Sinnvoller das ältere https://github.com/rq/django-rq zu nutzten.

[kbr]

Also ich hab eigentlich nicht viele gleichzeitige Events. Alles überschaubar.

Genau dafür ist eigentlich das von Dir in Deinem runner-Projekt schon einmal genutzte 'autotask' gedacht. Hauptsächlich für Cron-Jobs und eine nicht allzu hohe Menge an Events, da die django-db genutzt wird. Das macht die Installation dafür sehr einfach. Zwar gibt es bei dem Migrationsverhalten sowie der Skalierung noch etwas zu tun, davon abgesehen läuft die Anwendung aber stabil und ist bei mir seit gut zwei Jahren ohne Probleme im produktiven Einsatz.

Bei einem sehr hohen Event-Aufkommen brauchst Du natürlich eine andere Architektur. Die meisten Webanwendungen haben aber keine Last wie z.B. Zalando, sondern dümpeln gemächlich vor sich hin.

[jens]

Naja... Nur weil ich jetzt gerade keine hohen Ansprüche habe, sollte das ganze aber skalieren... Also es wäre toll, wenn man es, so wie "autotask" ohne viel drum herrum benutzten kann, aber auch das man auf redis setzten könnte...

Ich hab nunmal mit https://github.com/Koed00/django-q/ gespielt. Das kann die DB als "Broker" nutzten, aber auch redis und andere...

Aber, ich hab gleich ein paar Dinge gefunden:

https://github.com/Koed00/django-q/issues/316
https://github.com/Koed00/django-q/issues/317
https://github.com/Koed00/django-q/issues/318
https://github.com/Koed00/django-q/issues/319

Nur Kleinigkeiten, man kann work-a-round nutzten und vermutlich recht einfach zu fixen... Aber naja, hinterlässt dann doch kleinen guten Eindruck...

EDIT: Ich werde mir nun mal https://github.com/coleifer/huey/ ansehen...

[kbr]

Skalieren, das ist ein gutes Stichwort. Ab wann muss man eigentlich skalieren? Bleiben wir mal bei einer kleinen Webanwendung mit einer überschaubaren Zahl an Interessenten, sagen wir 10.000 Besucher pro Tag. Das ist für die meisten Websites schon recht viel. Und jeder Besucher schaut sich drei Seiten an; macht 30.000 Requests plus dem, was statisch nachgeladen wird. All das passiert nicht auf einmal, sondern über den Tag verteilt, zwar nicht gleichmäßig, aber eben doch verteilt. Für Nginx ist das überhaupt keine Last. Nehmen wir weiter an, eine halbwegs performante und nicht allzu rechenintensive django-Anwendung schafft mit einem Prozess so um die 20 Requests pro Sekunde – ohne Caching. Das sind bei 30.000 Requests ca. 25 Minuten Rechenzeit für die Tageslast. Mit Caching deutlich weniger. Solche Anwendungen sind von der Notwendigkeit einer Skalierung zumeist ein gutes Stück entfernt – und die meisten Anwendungen liegen noch weit darunter.

[jens]

Da magst du recht haben. Dennoch ist das bestreben da, ein Setup aufzubauen, was bis zu einer bestimmten Größe gut skaliert.

Ich hab nun ein wenig mit https://github.com/coleifer/huey/ gespielt. Macht bisher was es soll, bis auf https://github.com/coleifer/huey/issues/356 ... Aber die Django integration ist minimalistisch: Es gibt keine Django-Admin Integration. Das wäre allerdings schon nett.

Generell scheint mit huey auf das die Kernaufgabe konzentriert zu sein.
Es scheint keine nette CLI zu geben, mit der man besser sehen kann, was passiert
Anscheinend kann man nur zusehen, das man den "consumer" in ein log file schreiben lässt, damit man was "sehen" kann...

[jens]

Also https://github.com/coleifer/huey/ ist schon ganz nett... Allerdings vermisse ich da die Django Admin integration... Es scheint da auch nichts zu geben. Das müßte ich dann selber machen...

Dann wäre da noch: https://github.com/arteria/django-background-tasks
Das scheint mir aktiver zu sein als https://bitbucket.org/kbr/autotask und es hat anscheinend direkt die Django Admin integration, weil es eh alles in der Django DB speichert...

[DasIch]

Bei einem sehr hohen Event-Aufkommen brauchst Du natürlich eine andere Architektur. Die meisten Webanwendungen haben aber keine Last wie z.B. Zalando, sondern dümpeln gemächlich vor sich hin.

Zalando nutzt eine Microservice Architektur, die allermeisten der tausenden von services dümpeln gemächlich vor sich hin. Das ist mit ein Grund Events zu nutzen, du schiebst einfach mit Events alle Daten downstream und damit musst du dich nicht damit befassen APIs zu bauen die groß skalieren müssen und jede Menge traffic bekommen.

Statt Nakadi kannst du wie auch gesagt problemlos Events in SQS schieben und eine Lambda Funktion haben die dann ausgeführt wird. Alternativ Tabelle in einer Datenbank + Cronjob der alle 5min oder sogar jede Minute läuft, dürfte für die allermeisten dieser Use Cases vollkommen ausreichend sein und damit spart man sich komplexe Libraries wie Celery, die du zu 90% nicht brauchst und deren anderen 10% voll mit Bugs oder schwer verständlich sind.

[kbr]

Alternativ Tabelle in einer Datenbank + Cronjob der alle 5min oder sogar jede Minute läuft, dürfte für die allermeisten dieser Use Cases vollkommen ausreichend sein und damit spart man sich komplexe Libraries wie Celery, die du zu 90% nicht brauchst und deren anderen 10% voll mit Bugs oder schwer verständlich sind.

Diese Komplexität von Celery war die Motivation für 'autotask'. Für dieses Package gab es ursprünglich nur eine Zielgruppe, und die war ich. Und weil das Teil problemlos läuft, tut sich im Repository auch wenig, eben weil bislang keine schweren Fehler aufgefallen sind, die nun dringend behoben werden müssten. Was gewiss auch an der (vermutlich) geringen Verbreitung liegen dürfte. Wenn hier wirklich mal eine Skalierung erforderlich werden sollte, werde ich an die von Dir beschriebene eventgesteuerte Microservice Architektur denken – das scheint mir dafür ein geeigneter Ansatz zu sein.

[jens]

spart man sich komplexe Libraries wie Celery, die du zu 90% nicht brauchst und deren anderen 10% voll mit Bugs oder schwer verständlich sind.

Du sagst es.

@kbr: Jetzt merke ich erst, das du der Autor von autotask bist Dann sehen wir uns auf dem nächsten PyDDF Treffen

Also autotask möchte ich weiterhin gern in https://github.com/jedie/django-for-runners Dafür reicht es vollkommen. Es soll Anfragen an metaweather.com und openstreetmap async ausführen...

Aber in diesem Fall hab ich ein echtes Problem mit https://bitbucket.org/kbr/autotask/pull-requests/3/ denn ich führe die migration direkt beim ersten start automatisch aus, hier: https://github.com/jedie/django-for-run ... ver.py#L29
In diesem Fall, kann ich AUTOTASK_IS_ACTIVE zwar ändern, aber das ist dann schon ausgewertet. Wobei mir gerade einfällt: Ich könnte statt direkt call_command("migrate") auszuführen das ganze per subprocess machen, dann kann ich in der settings AUTOTASK_IS_ACTIVE dynamisch setzten... Das werde ich mal angehen, wenn ich wieder Zeit hab

Die die Arbeit hab ich mich nun entschieden https://github.com/coleifer/huey/ einzusetzen. Der Entwickler ist z.Z. recht aktiv und im test machte huey das was es soll. Das einzige was mir noch fehlt, ist die Django Admin integration: Ich möchte gern da ein Protokoll der tasks sehen. Insbesondere geht es mir darum, das per async verschickte mails quasi als "backup" abgelegt werden.
Aber ich denke das werde ich später dann selbst machen, siehe: https://github.com/coleifer/huey/issues/360

[kbr]

Aber in diesem Fall hab ich ein echtes Problem mit https://bitbucket.org/kbr/autotask/pull-requests/3/ denn ich führe die migration direkt beim ersten start automatisch aus, hier: https://github.com/jedie/django-for-run ... ver.py#L29

Ob ich diese Praxis für gut oder schlecht halte, weiß ich noch gar nicht. Den Thread habe ich aber zum Anlass genommen, über das Issue noch einmal nachzudenken. Die bisherigen Lösungsansätze hatten mir nicht gefallen, aber nun scheint mir etwas elegantes eingefallen zu sein, was auch Dein Problem lösen sollte. Falls mir das in den nächsten Tagen immer noch gefällt und auch gut umsetzbar ist, dann werde ich das einbringen. Und falls wir uns zuvor treffen sollten, können wir das gerne auch einmal durchsprechen

[jens]

Den Thread habe ich aber zum Anlass genommen, über das Issue noch einmal nachzudenken.

Prima, wenn es eine bessere Lösung gibt... Ich hab auch bei https://github.com/jedie/django-for-runners nun eine Lösung gefunden: Ganz so einfach ist es zwar nicht gewesen, aber nun mache ich es so, das AUTOTASK_IS_ACTIVE immer auf False gesetzt wird, außer der server wird gestartet. Und migration lasse ich vor dem server process laufen...

Jetzt muß ich allerdings noch die tasks wieder auslagern, damit sie auch asynchron laufen

[DasIch]

Insbesondere geht es mir darum, das per async verschickte mails quasi als "backup" abgelegt werden.

Keine generelle Lösung aber bei E-Mails, je nach Volumen, kannst du einfaches Monitoring/Backup dadurch erreichen einfach eine E-Mail Addresse fürs Monitoring immer in bcc zu tun.

[jens]

Das mit BCC ist eine Idee... Mal sehen...

Also mit Huey bin ich zufrieden! Ich hab das nun bei uns auf der Arbeit in den Docker/Django Stack aufgenommen und macht genau das was es soll