Sujet: 2012/10, Ca rame plus :D
05/10/2012 @ 15:12:32: zion: 2012/10, Ca rame plus :D
Plop,

14:14
zion : ça va, ça pulse bien aujourd'hui, pfiouf :petrus:
14:18
Derdesder : merci , le site va mieux :prosterne: :roi11: :prosterne2:
14:19
zion : on dirait, pfiouf hein, je te dis pas combien de soirées j'ai sué, mais bon... :smile:
14:20
zion : ça va, c'est le principal, demain je pourrai faire grasse mat! :grin:
14:58
ovh : ça mérite un ch'tit topic technique d'explications ? :cupra: on est friands d'infos :petrus:


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 :ddr555:

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 :petrus:

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 :grin:
05/10/2012 @ 15:30:26: blietaer: 2012/10, Ca rame plus :D
Tu vas à la pêche au bottleneck avec quoi? :figti:
Jmeter? :write:

Et donc en fait toi tu chies dans les poches de PHP ?
Ce site est vraiment écrit en.....Delphi ? :totoz:
05/10/2012 @ 15:46:45: zion: 2012/10, Ca rame plus :D
Je chie complètement dans les bottes de PHP pour les performances oui.

L'archi est compilée, et on rajoute une base de templates XML pour utiliser les composants qui sont disponibles, et un gros coup de CSS.

Delphi non, c'est sous Linux, c'est donc un ersatz de pascal objet, qui m'a permis il y a 10 ans de faire le boulot avec gestion d'interfaces sous Linux (ce qui n'existait pas à l'époque) alors que PHP était encore en train de discuter de comment ils allaient niquer l'orienté objet dans PHP5 :tinostar:

Pour le bottleneck, j'y vais à coup de logfile monsieur, et de bonnes lunettes :grin:
05/10/2012 @ 15:56:24: Clandestino: 2012/10, Ca rame plus :D
Donc, :prosterne:
05/10/2012 @ 16:00:22: zion: 2012/10, Ca rame plus :D
Pour Jmeter, j'ai pas besoin d'outils comme ça pour trouver les problèmes, vu que je domine l'architecture de A à Z avec mon code, je mesure chaque génération de page. Si je la trouve comme trop gourmande (je vérifie les ms pour chaque page et si il y a une fuite de mémoire), je log la requête.

Une fois que c'est loggé, suffit de relancer, de mesurer où précisément, et puis de trouver une solution.

J'ai jamais trop aimé les outils de test de charge, ça reflète rarement fidèlement l'utilisation du site, avec du Google, du bing, des anonymes, des inscrits, etc. Je reste plus fidèle de "chaque page doit se générer en un minimum de temps pour pas emmerder la suivante, quel que soit la page" :ddr555:
05/10/2012 @ 17:15:24: ovh: 2012/10, Ca rame plus :D

+1000, rien à dire :prosterne:


Et merci pour cette explication très intéressante :smile:
05/10/2012 @ 17:19:13: zion: 2012/10, Ca rame plus :D
De rien ! :grin:

J'aime bien PHP pour du scripting, mais dès que tu dois commencer à faire un truc qui pulse, tu dois oublier les array associatifs parce que ça bouffe en mémoire, et tout un autre tas de fonctions.

Pour un autre projet on charge des millions de rows en mémoire pour générer des stats, chargement, analyse, génération, rendering, 7 minutes, et ça monte à 130MB.
J'avais écrit (et si si optimisé) le code en PHP, ça bouffait des heures de CPU, et je parle même pas de la ram.
05/10/2012 @ 17:39:29: ovh: 2012/10, Ca rame plus :D
C'est clair que dès qu'il faut traiter des données volumineuses, PHP s'écroule, je le constate dans un projet client aussi.
05/10/2012 @ 18:09:01: zion: 2012/10, Ca rame plus :D
Allez, pour rire, je vous donne une ligne du code (un template XML) d'infos :grin:

  1. <forum:messages topic="%id%" limit="20" template="forum/browse/rows/rowmessage.xml" />


:petrus:
05/10/2012 @ 18:11:59: zion: 2012/10, Ca rame plus :D
Et la traduction en français, ça demande au moteur de prendre dans le module forum la classe qui implémente les messages, lui filer les quelques paramètres, et faire un rendu de chaque row qu'il va générer via un autre template. (qui lui aussi contient une série d'objets internes, etc).
05/10/2012 @ 18:24:51: Clandestino: 2012/10, Ca rame plus :D
Pour pratiquer le code dans les templates au quotidien, je confirme que le truc est d'une redoutable efficacité. On a même parfois un peu dur à retourner à du "bête" HTML par après...
07/10/2012 @ 19:53:13: testeurdesite: 2012/10, Ca rame plus :D
En tout cas ça pulse, ça groove, ça pète un max.
C'est chier quoi.
Un gourou noir (parce qu'il n'est pas roux du tout) quand ça sévit, c'est pas pour rire !
Là, je suis largué mais je confirme: le résultat déchire sa race.
:approuve:
07/10/2012 @ 20:04:53: zion: 2012/10, Ca rame plus :D
:tusors:

Vivement le vrai multi process n'empêche, dès que ce sera en place y aura la possibilité de certaines nouvelles choses ici... Vivement 2013! :itm:
08/10/2012 @ 09:59:36: ovh: 2012/10, Ca rame plus :D
Certaines nouvelles choses ? :write:
08/10/2012 @ 10:12:27: zion: 2012/10, Ca rame plus :D
Voui, y a toujours 2 ou 3 trucs que j'ai jamais voulu commencer à coder à cause de la limitation mono process, si y a des pages qui peuvent être plus longues du coup ce sera pas un soucis si chaque connecté a son propre canal :smile:

On verra en 2013 :tinostar:
08/10/2012 @ 19:56:35: Georgio: 2012/10, Ca rame plus :D
Belle explication... mais j'ai quand même rien capté :grin:
08/10/2012 @ 21:09:22: Delutilus: 2012/10, Ca rame plus :D
Belle explication... mais j'ai quand même rien capté :grin:



+1 (suis pas informaticien, programmeur, analyseur et tout et tout et tout...)
Retour