Se connecter
Inscription
Mot de passe perdu
Supprimer un message
Yup,
Depuis que le moteur d'info existe (plus de 10 ans), il tenait super bien la route en mono-coeur. A l'époque, avoir déjà un P4 (ou un sempron le premier serveur je pense), c'était un luxe, alors faire tourner plusieurs processus c'était pas toujours efficace.
Avec les années, augmentation substantielle de charge, des processeurs avec 8 coeurs, des machines avec 2 processeurs de 8 coeurs, bon, c'est clair que les limites d'hier ne sont plus celles d'aujourd'hui.
Problème pour multiplier les processus, à l'époque je me suis basé sur énormément de stockage en mémoire avec toute la génération en FastCGI liée à un processus unique qui tourne en permanence. Facile en dédié, et ça permet de garder tout ce qui est session en mémoire, et de faciliter pas mal d'opérations (des objets qui survivent d'une page à l'autre, voir qui continuent à bosser, etc). Faire évoluer ça en multi process, benh... oué, ... facile à dire, mais avec les plus de 10mb de sources, ça chie
Précédemment on avait
Lighttpd => Kelare. Point.
Il se fait que pour un autre projet, j'ai eu besoin de multiplier les processus dans une architecture distribuée, qui me permettait de contrôler exactement ce que j'attribuais à qui, et de pouvoir facilement répliquer toute modification sur les machines, et je passe encore la suite des contraintes.
On arrive donc maintenant à une architecture un rien plus lourde, mais qui permet de garder l'avantage de garder en mémoire des éléments clés, et à les faire bosser sans interaction, tout en ayant la génération de pages en multi processus, et capable de tourner en multi serveurs pour l'avenir.
Ca se résume à:
Lighttpd => Répartisseur de charge => Nodes Kelare
et
Nodes Kelare => Repository central d'objets
C'est pas totalement trivial, les objets en mémoire passant d'un processus à un autre, tout en continuant à bosser. Et je passe les nouveaux composants, un par serveur physique, qui lui aussi se connecte au répartisseur de charge et gère le nombre de nodes à la volée, en gérant tout ce qui est mise à jour de process.
Au final, ça tourne, et on voit pas de différence notable sur l'UI
Depuis que le moteur d'info existe (plus de 10 ans), il tenait super bien la route en mono-coeur. A l'époque, avoir déjà un P4 (ou un sempron le premier serveur je pense), c'était un luxe, alors faire tourner plusieurs processus c'était pas toujours efficace.
Avec les années, augmentation substantielle de charge, des processeurs avec 8 coeurs, des machines avec 2 processeurs de 8 coeurs, bon, c'est clair que les limites d'hier ne sont plus celles d'aujourd'hui.
Problème pour multiplier les processus, à l'époque je me suis basé sur énormément de stockage en mémoire avec toute la génération en FastCGI liée à un processus unique qui tourne en permanence. Facile en dédié, et ça permet de garder tout ce qui est session en mémoire, et de faciliter pas mal d'opérations (des objets qui survivent d'une page à l'autre, voir qui continuent à bosser, etc). Faire évoluer ça en multi process, benh... oué, ... facile à dire, mais avec les plus de 10mb de sources, ça chie
Précédemment on avait
Lighttpd => Kelare. Point.
Il se fait que pour un autre projet, j'ai eu besoin de multiplier les processus dans une architecture distribuée, qui me permettait de contrôler exactement ce que j'attribuais à qui, et de pouvoir facilement répliquer toute modification sur les machines, et je passe encore la suite des contraintes.
On arrive donc maintenant à une architecture un rien plus lourde, mais qui permet de garder l'avantage de garder en mémoire des éléments clés, et à les faire bosser sans interaction, tout en ayant la génération de pages en multi processus, et capable de tourner en multi serveurs pour l'avenir.
Ca se résume à:
Lighttpd => Répartisseur de charge => Nodes Kelare
et
Nodes Kelare => Repository central d'objets
C'est pas totalement trivial, les objets en mémoire passant d'un processus à un autre, tout en continuant à bosser. Et je passe les nouveaux composants, un par serveur physique, qui lui aussi se connecte au répartisseur de charge et gère le nombre de nodes à la volée, en gérant tout ce qui est mise à jour de process.
Au final, ça tourne, et on voit pas de différence notable sur l'UI
