27-11-2011, 03:29 PM
(Modification du message : 27-11-2011, 03:38 PM par Sephi-Chan.)
(27-11-2011, 02:22 PM)atra27 a écrit : Surement a cause de ça:
Citation :(dependant upon your traffic to your web site).
En gros si a l'heure prévue t'a un visiteur, c'est cool.
Mais si ton visiteur vient 1h après l'heure de ta tache, et bien ta tache aura été effectuée avec une heure de retard.
Non, ce n'est pas ça. Ça c'est le mécanisme utilisé par XNova (et sûrement pas mal de jeux Web qui tournent sur du mutualisé).
Là, c'est innefficace dans la mesure où le scheduler appelle une page Web à l'heure qu'on lui a donné. Donc ça passe par le serveur Web et ça lui occupe une connexion HTTP. Dans l'absolu, c'est moins efficace que de communiquer directement avec le serveur de queue (Redis dans le cas de Resque).
(27-11-2011, 02:22 PM)atra27 a écrit : Non la seule solution, c'est de se bouger un peu et de créer soit même sa lib d'interaction avec le processus Resque Scheduler.
Je connais pas resque, jamais testé, mais vu que ruby/php on l'air d’être tous deux dépendant d'un appel d'un client pour s’exécuter, le scheduling doit avoir lieu a un autre niveau, et si c'est le cas on doit pouvoir interagir avec ce niveau aussi bien en php qu'en ruby.
Corrigez moi si je me trompe mais peut être faudrait il penser a se créer des solutions par soit même plutôt que de chercher des solutions dans des libs.
@Sephi-Chan: y a moyen que tu poste le contenu de la méthode queue_in de ta classe ruby stp?
Effectivement, la solution c'est de se bouger et de porter Resque Scheduler. Ce que je trouve curieux, c'est que ce c'est la grosse communauté qui se fait piloter par la concurrence…
La méthode
enqueue_in. Elle délègue à enqueue_at, qui s'assure qu'on lui a donné une classe qui existe. Puis cette dernière délègue à enqueue_at_with_queue qui déclenche les éventuels hook puis délègue à son tour à delayed_push qui ajoute l'élément à la liste des éléments programmés à ce timestamp, puis ajoute la référence vers cette liste dans le sorted set (qui est donc un ensemble trié des timestamps auxquels il y a des tâches à effectuer).Ça, c'est donc les extensions effectuées sur Resque pour permettre de programmer des jobs.
Ça vaut bien une petite explication concernant le stockage de tout ça dans Redis.
Pour chaque timestamp auquel il y aura une tâche programmée, on aura une liste dans Redis. La clé de cette liste sera nommée selon le format
delayed:#{timestamp} et les éléments de la liste sont des objets JSON qui caractérisent les jobs à lancer à ce timestamp.Ensuite, on a donc un sorted set (un ensemble trié) qui aura pour clé
delayed_queue_schedule et qui contient donc les timestamps auxquels il doit se passer quelque chose. Ça permettra au Scheduler de mettre les éléments dans la vraie queue le moment venu.Et là on se rend compte que Redis c'est stylé ! Le modèle key-value et la variété de type de données rend ça vraiment intéressant !
Après, il y a encore la partie de Resque Scheduler qui va permettre au processus d'insérer les tâches dans Redis au moments voulus. Je détaillerais ça plus tard.
Ça se passe globalement dans la méthode
run de classe Resque::Scheduler.Il faut aussi penser que Resque Scheduler permet également d'avoir une liste de tâches récurrentes (stockée au format crontab).
iffle:
