19-08-2011, 07:22 PM
(Modification du message : 19-08-2011, 07:23 PM par Sephi-Chan.)
(19-08-2011, 06:18 PM)Maz a écrit : Je penses avoir un peu de mal à me faire comprendre. En même temps j'ai l'impression que c'est moi qui vois les choses pas comme il le faudrait. En fait je vois vraiment les blockbusters codé d'une manière différente pour mieux les gérer, un peu du genre:
Un logiciel client codé en php juste pour généré la source html final comme le ferais un simple moteur de template.
Un logiciel serveur codé en C, pour établir tous les calculs sur les informations envoyées par les formulaires du logiciel client.
Moi quand je code, bien que la partie formulaire est séparé de mes calculs via un moteur de template où via une architecture MVC, au final il n'y a qu'une page qui est exécuter qui fait les include des modèle, vue et contrôleur pour prendre mon dernier exemple.
Je comprends très bien de quoi tu parles : un daemon qui tournerait sur et s'occuperait de certains calculs. Et le serveur Web servirait juste d'intermédiaire.
Ça permet de s'affranchir de l'aspect stateless d'un serveur Web où tout ne vie que quelques instants (généralement moins d'une seconde).
Il y a beaucoup de tâches qu'il est plus intéressant d'effectuer de manière asynchrone : c'est beaucoup plus performant et efficace de les sortir du cycle d'une page Web puisque ça permet de n'avoir que des pages très rapide, donc des connexions au serveur Web très courte, donc pas de file d'attente des requêtes à l'entrée du serveur Web. Ça donne l'impression d'un site plus rapide.
C'est pour ça que j'insiste souvent sur l'utilisation d'outils de queuing comme Resque. Une utilisation bien connue de ce genre d'outils : l'envoi de mails, qui peut prendre plusieurs secondes.
C'est également pour ça qu'il faut utiliser des crons quand c'est possible. Ça permet de sortir beaucoup de choses du cycle de vie des requêtes HTTP : ça permet d'avoir un code plus simple et plus performant.
De nos jours, tout ça se marie très bien avec le push, puisque nos scripts exécutés tranquillement sur le serveur — en dehors d'une requête HTTP — deviennent capables de communiquer avec le navigateur.
Bref, le développement d'un daemon dédié n'est que la suite logique de tout ça. Mais avant d'en arriver là, il y a bien d'autres choses à faire.
