26-04-2011, 05:19 PM
(Modification du message : 26-04-2011, 06:18 PM par Sephi-Chan.)
Le cron est l'une des nombreuses méthodes pour faire ça, mais il y en a d'autres (un système de queue avec des workers, type Resque). C'est pour ça que l'utilisation d'Ajax (et dans une certaine mesure le push) est capitale, d'autant que sa nature asynchrone t'habitue à penser comme ça.
Un cas typique où l'asynchrone est plus efficace : un envoi de mails. C'est généralement une opération longue (dans le sens où ça dépasse la seconde) pour laquelle on peut rendre la main à l'utilisateur sans se soucier.
Avec un système synchrone, quand je vais cliquer sur mon formulaire, le script qui traite le formulaire d'envoi de mail est appelé, il envoie les mails et répond (il rend une page Web). Le problème, c'est que l'envoi de mail est lent et donc l'utilisateur va avoir l'impression que le site met du temps à répondre.
Avec un système asynchrone, on traite le formulaire de la même façon sauf qu'on envoie pas les mails directement, on met les informations pour les envoyer dans une queue (une fille d'attente) et on dispose d'un daemon (qui peut être installé sur la même machine, sur une autre ou même sur plusieurs machines) qui va lire cette file en exécutant les tâches mises en file. Ces outils supportent en plus plein de trucs cools comme la gestion des tâches qui échouent, la priorité des tâches, etc.
Les serveurs comme Apache ne sont pas adaptés à des requêtes longues (cas typiquement d'un script lents, qui va durer 10 secondes). Dans le cas d'une requête HTTP qui lance un script asynchrone, la requête va durer quelques millisecondes et sera de nouveau libérer pour un autre utilisateur.
Le gros avantage de l'asynchrone, outre la meilleure expérience pour l'utilisateur (puisqu'il n'a pas à attendre qu'une page charge lentement), c'est que ça se fait bien dans la durée et ça peut se faire quand le serveur a peu de charge.
Un autre avantage : le code reste propre, on n'a pas un plat de spaghettis qui déclenche des événements.
Cela ne veut pas dire pour autant qu'une tâche va être effectuée une plombe après avoir été mise en queue, les délais sont plus souvent de l'ordre de quelques secondes.
Après, déterminer ce qui doit être asynchrone se fait avec l'expérience. C'est propre à ton jeu et ses mécanismes. Et là dessus, on pourra probablement t'aider. Parfois, effectuer des actions synchrones est une meilleure idée.
Un cas typique où l'asynchrone est plus efficace : un envoi de mails. C'est généralement une opération longue (dans le sens où ça dépasse la seconde) pour laquelle on peut rendre la main à l'utilisateur sans se soucier.
Avec un système synchrone, quand je vais cliquer sur mon formulaire, le script qui traite le formulaire d'envoi de mail est appelé, il envoie les mails et répond (il rend une page Web). Le problème, c'est que l'envoi de mail est lent et donc l'utilisateur va avoir l'impression que le site met du temps à répondre.
Avec un système asynchrone, on traite le formulaire de la même façon sauf qu'on envoie pas les mails directement, on met les informations pour les envoyer dans une queue (une fille d'attente) et on dispose d'un daemon (qui peut être installé sur la même machine, sur une autre ou même sur plusieurs machines) qui va lire cette file en exécutant les tâches mises en file. Ces outils supportent en plus plein de trucs cools comme la gestion des tâches qui échouent, la priorité des tâches, etc.
Les serveurs comme Apache ne sont pas adaptés à des requêtes longues (cas typiquement d'un script lents, qui va durer 10 secondes). Dans le cas d'une requête HTTP qui lance un script asynchrone, la requête va durer quelques millisecondes et sera de nouveau libérer pour un autre utilisateur.
Le gros avantage de l'asynchrone, outre la meilleure expérience pour l'utilisateur (puisqu'il n'a pas à attendre qu'une page charge lentement), c'est que ça se fait bien dans la durée et ça peut se faire quand le serveur a peu de charge.
Un autre avantage : le code reste propre, on n'a pas un plat de spaghettis qui déclenche des événements.
Cela ne veut pas dire pour autant qu'une tâche va être effectuée une plombe après avoir été mise en queue, les délais sont plus souvent de l'ordre de quelques secondes.
Après, déterminer ce qui doit être asynchrone se fait avec l'expérience. C'est propre à ton jeu et ses mécanismes. Et là dessus, on pourra probablement t'aider. Parfois, effectuer des actions synchrones est une meilleure idée.