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

Tu vas à la pêche au bottleneck avec quoi?
Jmeter?

Et donc en fait toi tu chies dans les poches de PHP ?
Ce site est vraiment écrit en.....Delphi ?

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

Pour le bottleneck, j'y vais à coup de logfile monsieur, et de bonnes lunettes

Donc,

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"

+1000, rien à dire


Et merci pour cette explication très intéressante

De rien !

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.

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.

Allez, pour rire, je vous donne une ligne du code (un template XML) d'infos

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).

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...

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.

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!

Certaines nouvelles choses ?

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

On verra en 2013

Belle explication... mais j'ai quand même rien capté

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