Se connecter
Inscription
Mot de passe perdu
Supprimer un message
Plop,
Bon, alors, commençons par le début, il y a 10 jours, alors que Google boudait le site depuis qqs mois, il est revenu à la charge assez violemment.
Premier constat, alors que tout était stable, le pic a semble-t-il généré une certaine instabilité sur une version de kelare un peu ancienne (pour rappel kelare c'est le framework qui tourne derrière et est utilisé sur d'autres sites cfr bas de page).
J'ai donc passé en vitesse info sur la dernière version, 3 mois d'écart, et cette version corrigeait les soucis de stabilité, mais ça ramait sa mère en short sur la banquise.
Il faut savoir que pour le moment, Kelare est multi process. Quand on construit un truc comme info et le reste, on construit pas toujours ça directement pour supporter du clustering ou autre, on a quelques centaines de visiteurs et ça marche déjà tellement mieux qu'un PHP, alors on se dit qu'on verra.
Pour économiser un max de temps, il y a énormément de choses pré calculées en mémoire, et ça fait des économies monstrueuses au niveau DB, et disque, ce qui permet de générer 200.000 pages sur un xeon très modeste en SATA. Mais il se fait qu'à force, je vois le jour arriver où le système actuel, mono serveur, mono processeur, mono thread, aura ses limites, et que même si il faut garder un truc performant grâce à de judicieuses astuces par ci par là, le mono process a sa limite. C'est ce qui est en cours de réalisation sur la nouvelle mouture qui est en place.
Les bases sont en cours de réalisation pour du multi process, avec un processus mâitre qui lui continue à gérer toute la partie mémoire, et des processus esclaves pour générer les pages. Pour le moment tout n'est pas encore multi process, donc on garde un maître et un esclave, mais le but est bien d'avoir plein d'esclaves
Tout ça pour dire donc que sur le nouveau dialogue maître/esclave, j'ai une petite perte de quelques MS par rapport au processus actuel, et qu'avec Google ces petites MS sont vites devenues énormes, et il a donc fallu turbiner pour trouver tous les bottlenecks de cette nouvelle release
J'en ai trouvé un bon paquet, et au final personne peut voir la différence entre il y a 15 jours et maintenant, mais que la montée en charge se gère, doucement
14:14
zion : ça va, ça pulse bien aujourd'hui, pfiouf
14:18
Derdesder : merci , le site va mieux
14:19
zion : on dirait, pfiouf hein, je te dis pas combien de soirées j'ai sué, mais bon...
14:20
zion : ça va, c'est le principal, demain je pourrai faire grasse mat!
14:58
ovh : ça mérite un ch'tit topic technique d'explications ?
on est friands d'infos
zion : ça va, ça pulse bien aujourd'hui, pfiouf
14:18
Derdesder : merci , le site va mieux
14:19
zion : on dirait, pfiouf hein, je te dis pas combien de soirées j'ai sué, mais bon...
14:20
zion : ça va, c'est le principal, demain je pourrai faire grasse mat!
14:58
ovh : ça mérite un ch'tit topic technique d'explications ?
on est friands d'infos Bon, alors, commençons par le début, il y a 10 jours, alors que Google boudait le site depuis qqs mois, il est revenu à la charge assez violemment.
Premier constat, alors que tout était stable, le pic a semble-t-il généré une certaine instabilité sur une version de kelare un peu ancienne (pour rappel kelare c'est le framework qui tourne derrière et est utilisé sur d'autres sites cfr bas de page).
J'ai donc passé en vitesse info sur la dernière version, 3 mois d'écart, et cette version corrigeait les soucis de stabilité, mais ça ramait sa mère en short sur la banquise.
Il faut savoir que pour le moment, Kelare est multi process. Quand on construit un truc comme info et le reste, on construit pas toujours ça directement pour supporter du clustering ou autre, on a quelques centaines de visiteurs et ça marche déjà tellement mieux qu'un PHP, alors on se dit qu'on verra.
Pour économiser un max de temps, il y a énormément de choses pré calculées en mémoire, et ça fait des économies monstrueuses au niveau DB, et disque, ce qui permet de générer 200.000 pages sur un xeon très modeste en SATA. Mais il se fait qu'à force, je vois le jour arriver où le système actuel, mono serveur, mono processeur, mono thread, aura ses limites, et que même si il faut garder un truc performant grâce à de judicieuses astuces par ci par là, le mono process a sa limite. C'est ce qui est en cours de réalisation sur la nouvelle mouture qui est en place.
Les bases sont en cours de réalisation pour du multi process, avec un processus mâitre qui lui continue à gérer toute la partie mémoire, et des processus esclaves pour générer les pages. Pour le moment tout n'est pas encore multi process, donc on garde un maître et un esclave, mais le but est bien d'avoir plein d'esclaves
Tout ça pour dire donc que sur le nouveau dialogue maître/esclave, j'ai une petite perte de quelques MS par rapport au processus actuel, et qu'avec Google ces petites MS sont vites devenues énormes, et il a donc fallu turbiner pour trouver tous les bottlenecks de cette nouvelle release
J'en ai trouvé un bon paquet, et au final personne peut voir la différence entre il y a 15 jours et maintenant, mais que la montée en charge se gère, doucement
