[PHP] Resque ou Rediska et Redis : je rame complétement...

[php_addict]

C'est un processus Ruby qui s'occupe du scheduling. Dans la méthode run de classe Resque::Scheduler.

Si c'est un processus ruby qui schelude a l'heure prévue dans redis dans ce cas c'est pas jouable en php.

oui effectivement ca va être chaud...petit question à ce sujet, la commande QUEUE (console) ca vient de quoi? redis? resque ? autre

La dernière fois php_addict tu parlais de grand jeu même s'il n'est pas si grand, il y a empire univers 2 qui fonctionne toutes les 1 minutes.
Pour dire qu'il y a des jeux populaires avec un rafraîchissement par minute sans que cela pose problème pour le joueur.

ok, mais il y a forcément le déclenchement de la résolution des actions quand un joueur affiche une page web sinon il doit attendre 1 minutes...

De plus je met en garde contre ces méthodes: si l'appli ruby est déchargée du serveur a l'heure ou la tache doit étre lancée...
De plus si les workers sont occupés a l'heure prévue, la tache ne s'effectuera pas a l'heure ou elle devrais mais aprés l'heure!

oui ou en cas de reboot du serveur, ca c'est difficile à gérer je pense...

bon pour le moment j'en suis à communiquer avec redis avec les sockets sur le port adéquat, j’arrive à lancer les commande PING, INFO, mais j'ai un soucis avec GET et SET...

pour le schedulding je n'ai absolument aucune idée de comment ca va se passer et si je vais y parvenir...

[Sephi-Chan]

oui effectivement ca va être chaud...petit question à ce sujet, la commande QUEUE (console) ca vient de quoi? redis? resque ? autre

Aucune idée. Je n'ai pas cette commande.

De plus je met en garde contre ces méthodes: si l'appli ruby est déchargée du serveur a l'heure ou la tache doit étre lancée...
De plus si les workers sont occupés a l'heure prévue, la tache ne s'effectuera pas a l'heure ou elle devrais mais aprés l'heure!

oui ou en cas de reboot du serveur, ca c'est difficile à gérer je pense...

Pas plus qu'Apache… Tu installes ton scheduler comme un service, comme tu le fais déjà avec Apache, MySQL, etc.
/etc/init.d ça doit te parler !

bon pour le moment j'en suis à communiquer avec redis avec les sockets sur le port adéquat, j’arrive à lancer les commande PING, INFO, mais j'ai un soucis avec GET et SET...

pour le schedulding je n'ai absolument aucune idée de comment ca va se passer et si je vais y parvenir...

Pourquoi est-ce que tu te compliques toujours la vie ?
Pourquoi ne pas simplement utiliser un client Redis pour PHP ?

[php_addict]

oui effectivement ca va être chaud...petit question à ce sujet, la commande QUEUE (console) ca vient de quoi? redis? resque ? autre

je pensais à :

$ QUEUE=* APP_INCLUDE=./config/init_worker.php php resque.php

Pourquoi est-ce que tu te compliques toujours la vie ?
Pourquoi ne pas simplement utiliser un client Redis pour PHP ?

pour apprendre, c'est mon mode d'apprentissage...j'arrive pas à faire autrement...

[Sephi-Chan]

je pensais à :

$ QUEUE=* APP_INCLUDE=./config/init_worker.php php resque.php

Je cite mon message explicatif :

$ QUEUE=* APP_INCLUDE=./config/init_worker.php php resque.php

Ici, la ligne définie deux variables d'environnement (qui seront seulement définies le temps de la commande) puis demande ensuite à l'intérpréteur PHP d'exécuter le fichier resque.php fourni avec Resque PHP. Ça va lancer un processus qu'on pourra kill quand on en aura marre.

La variable QUEUE permet d'indiquer la ou les queues à traiter : toutes, dans notre cas.
La variable APP_INCLUDE permet d'inclure un fichier. En l'occurrence, ce fichier fera des include des classes qu'on utilise dans notre tâche, établira la connexion à la base de données, etc.

Pourquoi est-ce que tu te compliques toujours la vie ?
Pourquoi ne pas simplement utiliser un client Redis pour PHP ?

pour apprendre, c'est mon mode d'apprentissage...j'arrive pas à faire autrement...

Tu as recordé aussi les fonctions pour interagir avec MySQL quand tu as appris à faire du SQL ? iffle:

Plus sérieusement, tu ne veux pas d'abord mettre en place Resque et du scheduling avant de t'attaquer à la communication avec un serveur Redis ?

Tu es un peu difficile à suivre pour ceux qui veulent t'aider…

[php_addict]

Tu as recordé aussi les fonctions pour interagir avec MySQL quand tu as appris à faire du SQL ? iffle:

:$ oh la vache...j'avais pas les yeux en face des trous quand j'ai dit ca...bref...

petite question concernant resque schedulder:

je pensais que l'on pouvait faire une tache planifier à la seconde près, genre à 13 h 52 min 18 sec, mais je n'en suis pas si certain maintenant, peut tu confirmer stp?

[Sephi-Chan]

A l'heure prévue, Resque Scheduler va ajouter l'élément dans la queue de Resque. Tu n'as pas la garantie absolue que Resque exécute cette tâche à cet instant là. Il peut y avoir un décalage de 1 seconde ou plus si le worker est déjà occupé.

Mais de toute façon ça c'est propre à l'asynchrone et si tu as réellement besoin de la seconde près, change de système. ^^

[atra27]

Oui je savais que redis c'etait pour faire de l'asynchrone, et je reconnais que ce truc est génial pour liberer le thread apache plus vite.

Je sais pas si je l'ai lu quelque part ici (suis pas super attentif a ce que je lis ces derniers temps), mais j'avais dans l'idée qu'on pouvais s'en servir pour la résolution d'action. Sauf que la je me rend compte que si on l'utilise c'est uniquement pour sa capacité a lancé des taches a une heure précise, mais pas a executer une tache a cette heure! (donc on répond pas a 100% a la problématique)
Donc en prennant ça en compte, finalement mon systeme de résolution lorsqu'on a besoin des infos correspondantes est pas si mal...

Aurai au moins appris un nouveau truc aujourd'hui!

[Sephi-Chan]

Oui je savais que redis c'etait pour faire de l'asynchrone, et je reconnais que ce truc est génial pour liberer le thread apache plus vite.

Je sais pas si je l'ai lu quelque part ici (suis pas super attentif a ce que je lis ces derniers temps), mais j'avais dans l'idée qu'on pouvais s'en servir pour la résolution d'action. Sauf que la je me rend compte que si on l'utilise c'est uniquement pour sa capacité a lancé des taches a une heure précise, mais pas a executer une tache a cette heure! (donc on répond pas a 100% a la problématique)
Donc en prennant ça en compte, finalement mon systeme de résolution lorsqu'on a besoin des infos correspondantes est pas si mal...

Aurai au moins appris un nouveau truc aujourd'hui!

Et bien je pense que c'est très bien pour la résolution d'action aussi. Ce que je veux te dire, c'est que tu si tu as réellement besoin de traitement à la seconde près — mais généralement ce ne sera pas le cas — ton application Web ne sera pas très bonne car trop sensible.

Faire tes résolutions à la demande peut ne pas être mal selon la complexité de la résolution. Si c'est complexe et donc coûteux en temps, alors mieux vaut le faire hors de la requête HTTP et utiliser du push pour mettre à jour l'interface.

Après, c'est du cas par cas selon les jeux et les besoins. Mais je pense que tous les jeux Web ont intérêt à faire tout ce qui est un peu complexe en background.

[atra27]

De toute façon je compte utiliser redis pour les traitements lourds.
Mais en aucun cas ça ne dispense du bout de code censé faire comme si l'action se déroulait a l'heure prévue, même si elle est exécutée après!

Conclusion: ma méthode est bonne, et un système de résolution comme le mien peut être utilisé a la demande via un appel a une méthode de ma lib update (avec param pour l'user a update, ou faire l'appel depuis redis, en passant ou pas le paramétre)

[Sephi-Chan]

Ça ne nous avance pas beaucoup puisque tu ne décris pas de ton cas d'utilisation…