Comments on: s&m.5.lezy…out@spamgourmet.net => erreur

By: qkdreyer

qkdreyer — Tue, 19 Mar 2013 10:17:46 +0000

Il existe aussi Beanstalkd, qui à l’air assez simple d’utilisation : http://dev.af83.com/2013/03/13/why-you-should-consider-beanstalkd.html

By: Sam

Sam — Sat, 16 Mar 2013 12:15:18 +0000

En effet, rabbitMQ est un broker particulièrement centralisé. Si tu as besoin de répartition, soit il faux sharder les queues, soit il faut un backend qui tappe dans un truc qui se load balance tout seul.

Même si tu gardes cassandra pour cette raison, je t’invite à jeter un coup d’oeil à celery, car ça t’évite de te taper la logique des queues, du verrouillage, du routing, etc.

Après, le KISS reste une très bonne chose, ajouter un composant juste pour l’ajouter n’a effectivement aucun sens, et tu rajoute un point de faiblesse.

By: hdsdi3g

hdsdi3g — Sat, 16 Mar 2013 12:09:28 +0000

RabbitMQ semble intéressant. Il est en tout cas assez facile de l’attaquer en Java. Après je doute qu’il soit décentralisé.
Au niveau des perfs et du load je n’ai pas de problèmes (et j’en suis très loin d’en avoir à ce niveau). C’est plus au niveau de la scalabillité et de la simplicité que ça coince.
Je n’ai pas envie de rajouter un point de faiblesse, ni pour autant rajouter des couches et avoir un code qui tourne sur une usine à gaz. Bref, les perfs, je m’en fou, par contre ça doit être simple et résistant. J’ai même pensé un temps à utiliser l’API de git.

By: Sam

Sam — Sat, 16 Mar 2013 11:40:01 +0000

Cassandra c’est déjà du NOSQL, c’est un peu plus adapté. Mais si tu veux faire une migration en douceur, prend celery et son backend cassandra:

http://docs.celeryproject.org/en/latest/internals/reference/celery.backends.cassandra.html

Tu passes tes tâches sous celery, la sémantique change, mais ta config reste la même.

Puis quand tu es à l’aise avec celery, tu installe un backend plus adapté : redis voir carrément rabbitMQ. Et là tu déchargera cassandra, sans changer le code de tes tâches. Migration en douceur. Normalement tu devrais gagner en load average et en découplage dans ton archi (enfin, faut mesurer, comme d’hab).

Mais si tu es à l’aise avec ton système actuel et que ça bouffe pas trop, il n’y a pas de raison de changer. Il y a des choses plus prioritaires que de changer son système de queue. C’est pour cette raison qu’on garde kombu d’ailleurs, alors que celery est plus adapté : y a du boulot ailleurs.

By: hdsdi3g

hdsdi3g — Sat, 16 Mar 2013 10:54:45 +0000

Intéressant.
Ça me pousse à réfléchir et à remettre en cause l’utilisation de Cassandra pour ça (car il y a des locks, de la répartition et de la consistance). J’ai ce qui faut, mais c’est pas très pratique, et un peu lourd pour ça.
J’ai peur par contre de tomber sur des outils usine à gaz et bien complexes (tel qu’on sait les faire en Java) mais c’est un sujet à creuser, en effet.

By: Sam

Sam — Sat, 16 Mar 2013 10:44:27 +0000

- Ca ne bouffe pas de ressource dans la base de données. Poll + lock + write par 20 workers en parallèle toute la journée, c’est pas négligeable.
– Tu n’as pas à implémenter la logique de polling, de routing, de séparation de queues, de priorités, etc. Beaucoup de travail et de bug en moins.
– Tu peux mettre plusieurs workers qui consomment depuis la même queue sans te soucier de la concurence ou du locking. Ca va couler tout seul.
– C’est fait et optimisé pour ça.
– La sémantique de l’outil fait que le code est clair, tu créer une tache, tu envois une tache, tu chaine une tache, etc.

Plus d’infos:

http://blog.gomiso.com/2012/11/15/asynchronous-processing-in-web-applications-part-1-a-database-is-not-a-queue/
https://blog.engineyard.com/2011/5-subtle-ways-youre-using-mysql-as-a-queue-and-why-itll-bite-you

By: hdsdi3g

hdsdi3g — Fri, 15 Mar 2013 23:00:58 +0000

Et qu’apporte ce genre d’outils par rapport à une base de donnée qui peut locker des ressources ?

By: Sam

Sam — Fri, 15 Mar 2013 22:56:32 +0000

Oui c’est ça. C’est un gestionnaire de queues. Il permet de faire des files d’attentes, et d’empiler des messages dedans d’un côté, tout en les dépilant de l’autre. Les queues peuvent être stockées dans différents transports: redis, rabbitMQ, etc.

Nous utilisons Kombu historiquement, mais si quelqu’un doit commencer un nouveau projet, je recommande d’utiliser celery, qui est d’un plus haut niveau que kombu et demande de moins mettre les mains dans la cambouis.

By: hdsdi3g

hdsdi3g — Fri, 15 Mar 2013 22:29:58 +0000

Humm "kombu" ? Qu'est ce ? Ceci https://github.com/celery/kombu ? Qu'est ce que ça fait au juste ?

By: Sam

Sam — Fri, 15 Mar 2013 19:22:28 +0000

@Lezy

Il n’y a pas de solution miracle, mais tu peux par contre probablement uploader et encoder à la volée. Tu encode le fichier, et tu upload le résultat au fur et à mesure. Comme la les deux temps de processing sont en parallèle.

Nous on utilise un jwplayer custo.