30-04-2011, 05:29 PM
(Modification du message : 30-04-2011, 05:43 PM par Sephi-Chan.)
Hélas, ça demande un peu plus que des connaissances avancées en développement Web.
Imagine un serveur qui pilote des files de production. Depuis notre script, on s'y connecte (socket TCP, donc programmation réseau), on lui envoie des commandes : crée la queue Q1, ajoute-y l'élement E1 qui commence à T1 et dont la production durera D1. Quand c'est fini, notifie-le moi (par socket ou par HTTP ? Les deux ?) en m'envoyant le nom de la file et l'élément terminé.
Ça implique d'avoir un daemon, donc un processus avec une longue durée de vie et dont la consommation en mémoire doit être très bien maîtrisée (pas de fuite).
Ça implique également de tenir la charge et être extensible (scalability) : faire évoluer 10 queues et 100 000, ce n'est pas pareil (bien sûr, le matériel importe). Ça doit éventuellement pouvoir être distribué (utiliser plusieurs machines).
Le logiciel serveur doit pouvoir recevoir des commandes (pour ajouter des éléments en queue, modifier les queues, suspendre temporairement un élément, etc.) et en émettre (signaler au client qu'une production est terminée).
Rien qu'avec ça, il y a de quoi occuper !
Il y a moyen de construire ce serveur à l'aide de composants existants et relativement accessibles : le daemon peut être réalisé avec des outils comme NodeJS (Javascript), Twisted (Python), EventMachine (Ruby) ou autre. Le stockage des queues peut-être assuré par Redis, MongoDb ou autre (éventuellement une base de données SQL, même si je doute que ce soit un choix pertinent).
Après, le point qui me paraît le plus obscur, c'est la progression de la file. C'est le point sur lequel je suis le moins à l'aise (je passe probablement à côté de plusieurs solutions aux problèmes).
Est-ce qu'on fait monter la file de manière synchrone de façon à pouvoir consulter sa progression en temps réel ? En ayant par exemple un processus par file (100 000 files = 100 000 processus ?) ? Ou plusieurs processus "workers" qui prennent chacun en charge plusieurs files ?
Ensuite, est-ce que ces processus se contentent alors d'augmenter l'état de progression de l'élément actif (s'il y en a un) de chaque file au fil du temps (plus pratique si on veut supporter des fonctionnalités comme l'arrêt ou le ralentissement temporaire de la vitesse de production) ? Ou bien ils font un bête sleep d'une durée équivalente à la durée de production de l'élément puis le marquent comme terminé (probablement plus performant) ?
Voilà, c'est là que j'aurais besoin de l'avis de personne qualifiées dans ce domaine : les différentes façon de compter le temps au sein d'un daemon. Les possibilités doivent être nombreuses mais je n'en entrevois qu'une partie dont j'ignore l'efficacité.
Le problème : je ne sais pas à qui demander de l'aide. :/
Imagine un serveur qui pilote des files de production. Depuis notre script, on s'y connecte (socket TCP, donc programmation réseau), on lui envoie des commandes : crée la queue Q1, ajoute-y l'élement E1 qui commence à T1 et dont la production durera D1. Quand c'est fini, notifie-le moi (par socket ou par HTTP ? Les deux ?) en m'envoyant le nom de la file et l'élément terminé.
Ça implique d'avoir un daemon, donc un processus avec une longue durée de vie et dont la consommation en mémoire doit être très bien maîtrisée (pas de fuite).
Ça implique également de tenir la charge et être extensible (scalability) : faire évoluer 10 queues et 100 000, ce n'est pas pareil (bien sûr, le matériel importe). Ça doit éventuellement pouvoir être distribué (utiliser plusieurs machines).
Le logiciel serveur doit pouvoir recevoir des commandes (pour ajouter des éléments en queue, modifier les queues, suspendre temporairement un élément, etc.) et en émettre (signaler au client qu'une production est terminée).
Rien qu'avec ça, il y a de quoi occuper !
Il y a moyen de construire ce serveur à l'aide de composants existants et relativement accessibles : le daemon peut être réalisé avec des outils comme NodeJS (Javascript), Twisted (Python), EventMachine (Ruby) ou autre. Le stockage des queues peut-être assuré par Redis, MongoDb ou autre (éventuellement une base de données SQL, même si je doute que ce soit un choix pertinent).
Après, le point qui me paraît le plus obscur, c'est la progression de la file. C'est le point sur lequel je suis le moins à l'aise (je passe probablement à côté de plusieurs solutions aux problèmes).
Est-ce qu'on fait monter la file de manière synchrone de façon à pouvoir consulter sa progression en temps réel ? En ayant par exemple un processus par file (100 000 files = 100 000 processus ?) ? Ou plusieurs processus "workers" qui prennent chacun en charge plusieurs files ?
Ensuite, est-ce que ces processus se contentent alors d'augmenter l'état de progression de l'élément actif (s'il y en a un) de chaque file au fil du temps (plus pratique si on veut supporter des fonctionnalités comme l'arrêt ou le ralentissement temporaire de la vitesse de production) ? Ou bien ils font un bête sleep d'une durée équivalente à la durée de production de l'élément puis le marquent comme terminé (probablement plus performant) ?
Voilà, c'est là que j'aurais besoin de l'avis de personne qualifiées dans ce domaine : les différentes façon de compter le temps au sein d'un daemon. Les possibilités doivent être nombreuses mais je n'en entrevois qu'une partie dont j'ignore l'efficacité.
Le problème : je ne sais pas à qui demander de l'aide. :/