Bonjour à vous aux grands oracles du forum !

Je rencontre de plus en plus souvent des lenteurs qui aboutissent en erreur 522 quand je parcours le forum.
C'est un peu irritant et ca m'oblige à moins venir sur le forum, y'a t il des solutions ?
Puis je aider ? (techniquement j'entends) J'ai du temps à tuer et des compétences en infra web.

Suis je le seul ? Y'a pas forcément d'heures ou de moments particulier.
Y'a t il un endroit ou je puisse analyse les métriques ?

Par avance merci

C’est pareil pour moi 😓

Mêmes symptômes de mon côté 🥲

Idem, c'est aléatoire et assez rare, mais cela fait déjà quelques mois que ça m'arrive (je ne suis pas aussi assidu que d'autres lol)...

Modifié le 16 juilletle 16 juil. par roulio67

Oui cela m'arrive très souvent mais je connais parfaitement les galères liées à tout ça surtout en ce moment donc 🤫 courage mais si effectivement certains peuvent aider alors à votre bon cœur 😊

Cool si tu peux aider ami chômeur 🤣

il y a 23 minutes, M-Dias a dit :

Cool si tu peux aider ami chômeur 🤣

On fait comme on peut, merci les gars pour le chomage :

À l’instant

Merci pour les différents retours, je suis en train d'investiguer !

Coucou la compagnie,

Je viens aux nouvelles concernant les lenteurs et les erreurs 522 aperçues sur le forum depuis un moment ! 👀

Je vais être un peu technique mais je vais surtout essayer de simplifier au maximum pour tout le monde.

J'ai passé le week-end + ce lundi à dézinguer tout ce qui bougeait sur la plateforme, que ce soit les configurations des services, les valeurs sysctl (paramétrage système), le réseau, etc.

Bref, j'ai remis tout le travail en question pour au final tomber sur une chose simple : les configurations sont bonnes, pour ne pas dire excellentes (il y a toujours un truc à optimiser ou à corriger, mais globalement on est bien tintin). 👌

Dans la nuit de samedi à dimanche (ou dimanche à lundi, je suis un peu largué), je suis tombé sur une vidéo sur X d'un gars qui a testé le comptage entre 2 langages, l'un en C++ et l'autre en Python. L'idée est de faire le compte jusqu'à 1 milliard. Bref, dans le monde des devs, c'est une boucle qui va faire tout simplement 0, 1, 2, 3, … 1 000 000 000.

Pour ceux qui ne regarderont pas la vidéo, et pour ceux à qui les langages informatiques ne disent rien, voilà la différence en deux mots.

Le C++ est un langage compilé. Avant de pouvoir s'en servir, on passe le code à la moulinette d'un compilateur qui le traduit une fois pour toutes en langage machine, celui que le processeur comprend directement. Le programme qui en sort ne traduit plus rien : il s'exécute, point.

Python, lui, est un langage interprété. Pas de compilation préalable : le code est converti en une forme intermédiaire (le bytecode), puis exécuté par une machine virtuelle qui déroule ces instructions une par une, à chaque exécution.

L'image qui marche bien : le C++, c'est un livre traduit et imprimé une bonne fois pour toutes, vous lisez directement la traduction. Python, c'est un interprète assis à côté de vous qui traduit chaque phrase au fur et à mesure, à chaque fois que vous parlez. Il est très rapide, mais il y a forcément quelqu'un qui travaille pendant que vous écoutez.

D'après la vidéo, en C++ pour compter jusqu'à 1 milliard, il lui faut environ 2,4 secondes : rapide, clair et efficace. Pour Python c'est une autre chanson, car il a fallu attendre 1 min 52 s !

Quel est le rapport avec le forum ?

C'est assez simple : le forum fonctionne avec le langage PHP, qui est du même calibre que Python ! C'est-à-dire que c'est du script, et donc il faut une machine virtuelle qui traduit le code PHP en code machine pour que l'ordinateur puisse faire le travail !

J'ai repris la même idée que le gars sur X, mais cette fois je n'ai pas tapé dans le milliard, plutôt dans les 10 millions à calculer. Ça donne un bon échantillonnage global, bien qu'il faille garder à l'esprit que dans cette pratique, on ne fait que compter ! Le forum est complexe, car ce sont des appels de classes/fonctions, etc. Mais ça donne une idée du temps processeur qu'il faut tout de même pour afficher le résultat !

Donc en gros, j'ai fait en ligne de commande la demande de calcul et je lui ai demandé d'afficher le temps qu'il faut pour répondre (en millisecondes) :

$ php -r '$t=microtime(true);$x=0;for($i=0;$i<10000000;$i++){$x+=$i*2;}echo round((microtime(true)-$t)*1000)."ms\n";'
288ms

Il faut donc 288 ms à la machine du forum pour compter jusqu'à 10 millions. C'est long, trèèès long ! Surtout que PHP ne fonctionne qu'en mono-thread (comprendre : une page = un seul cœur du processeur, impossible de répartir le travail sur plusieurs) !

Et pour anticiper la question : oui, on peut mettre ce bytecode en cache pour éviter de le recalculer à chaque visite, c'est le rôle de l'OPcache de PHP, et il tourne parfaitement sur le forum, j'ai vérifié. Mais ça ne supprime que l'étape de traduction. Le déroulé instruction par instruction, lui, reste à faire à chaque page affichée. Et c'est exactement là que la vitesse brute d'un cœur de processeur devient déterminante.

Comme je l'ai dit avant, il faut prendre en compte que le forum est complexe et utilise des fonctionnalités qui rendent l'affichage d'une page plus long. Sans OPcache, il faut environ 1,02 s ; avec, 800 ms. Cela peut varier en fonction des pages visitées, mais rien que pour la page principale du forum, avec tous les forums disponibles, le calcul du nombre de sujets et de messages fait que cette page prend du temps !

« Waiting for server response », c'est le TTFB : le temps entre votre demande et le premier caractère de réponse. Pendant ce temps, votre navigateur attend pendant que le serveur exécute le code PHP, interroge la base et fabrique la page. Ici : 778 ms à fabriquer la page, 0,94 ms à vous l'envoyer. Ce n'est donc pas un problème de connexion — c'est le serveur qui met du temps à réfléchir.

J'ai testé la même méthode de calcul avec un autre serveur qui nous sert pour les sauvegardes, la métrologie et un tas d'autres choses. Il est plus récent que celui du forum :

$ php -r '$t=microtime(true);$x=0;for($i=0;$i<10000000;$i++){$x+=$i*2;}echo round((microtime(true)-$t)*1000)."ms\n";'
94ms

Et en moyenne l'affichage d'une page prend dans les 240-250 ms, bien plus rapide !!!

Petite précision d'honnêteté : ce test a été réalisé en direct sur la machine, sans passer par Cloudflare. Il faudra prendre en compte le trajet par le CDN, comptez donc plutôt autour de 350 ms au lieu des 800 actuelles. Ça reste plus de deux fois plus rapide !

Même page, même code, même base de données mais seule la machine change. Le serveur ne met plus que 243 ms à fabriquer la page, contre 778 ms. Le transfert, lui, est identique : 1,4 ms. Toute la différence est dans le temps de réflexion.

Donc voilà le premier point pour les lenteurs. En ce qui concerne les erreurs 522, elles sont produites par Cloudflare, qui nous permet de distribuer les pages (c'est un CDN). L'erreur 522 est une erreur personnalisée par leurs soins, mais le message est clair : un timeout. Aux heures de pointe, quand tout le monde arrive en même temps, notre loyal serveur sature complètement et ne répond plus assez vite. Cloudflare attend, puis abandonne et affiche cette page d'erreur.

Alors voilà où tout ça nous mène. J'aurais adoré trouver une bêtise dans un fichier de configuration — ça se corrige en cinq minutes et on n'en parle plus. Mais non : le forum va bien, les réglages vont bien, c'est la machine qui ne suit plus. Il nous en faudrait une nouvelle.

PHP a évolué, le forum aussi, mais le matériel n'a pas suivi. 🤖

Nous réfléchissons aux alternatives disponibles, mais le problème, je ne vous l'apprends pas, c'est le prix ! Autant, si le forum n'était pas un gros bébé, ce serait simple ; mais... c'est un gros bébé, donc il faut une grosse machine, plus récente. Dans l'idée, il faudrait pouvoir passer d'une M3 E36 à une M3 E92 (voire plus) ! 🚗

Voilà pour le pavé ! J'ai été technique sur la partie exécution, mais je vous ai épargné toute la machinerie réseau et les schémas de fonctionnement. Si vous voulez creuser un point précis, demandez, ça me fera plaisir d'en parler. 😅

Cordialement, Alban

Bonjour et merci Alban.

C’est possible de faire un appel aux dons des membres pour payer le prix pour avoir une plus grosse machine?

Incroyable ! j’ai « presque » compris !

Merci 1000 fois pour le temps que tu as pris et le travail effectué 🙏🏻

Modifié le 4 aoûtle 4 août par Stef-R

Je vois que @TheArchitect n'a pas fait dans la dentelle au niveau des explications 😅

Pour l'instant, j'essaie de contenir le coût du forum autour de 200€ à 300€/mois (serveur, nom de domaine, licence, IP, serveur mail, etc) pour des adhésions/dons qui dépassent rarement 1000€/an. Enfin bref, on réfléchit aux solutions !

moi , j'ai rien compris mais je suis content 😇

mais bon là il faut que je m'absente 😂

Il y a 2 heures, ACS3 a dit :

moi , j'ai rien compris mais je suis content 😇

mais bon là il faut que je m'absente 😂

Mais si, c'est facile. Le serveur fonctionne comme le moteur de @GuiOm , et Paul et l'architecte s'arrachent les cheveux pour le faire marcher comme un V8 d'E92.

Salut,

Bravo pour l’enquête et pour les explications 👍

J’imagine que tu as aussi regardé du côté de la base de données, et en particulier de ses index ? J’ai déjà rencontré un cas un peu similaire : des index étaient manquants, donc les requêtes étaient plus longues. Pendant ce temps, des tables étaient verrouillées, et les requêtes php s’empilaient pour terminer leur traitement (attente de libération des verrous).

Tout ça se matérialisait par une hausse de la cpu, cpu utilisée essentiellement par php - bien que le soucis vient de mysql/mariadb. Tu peux regarder du côté des logs slow query pour voir si quelques requêtes sont lentes.

Voilà, si ça peut aider 😊

Bonne journée

il y a une heure, vincent_ a dit :

Salut,

Bravo pour l’enquête et pour les explications 👍

J’imagine que tu as aussi regardé du côté de la base de données, et en particulier de ses index ? J’ai déjà rencontré un cas un peu similaire : des index étaient manquants, donc les requêtes étaient plus longues. Pendant ce temps, des tables étaient verrouillées, et les requêtes php s’empilaient pour terminer leur traitement (attente de libération des verrous).

Tout ça se matérialisait par une hausse de la cpu, cpu utilisée essentiellement par php - bien que le soucis vient de mysql/mariadb. Tu peux regarder du côté des logs slow query pour voir si quelques requêtes sont lentes.

Voilà, si ça peut aider 😊

Bonne journée

à tes souhaits 🤣

2 minutes ago, ACS3 said:

à tes souhaits 🤣

Mais tellement, j'ai lu j'ai été pris d'une migraine instantanée...

Le 04/08/2026 à 10:13, Paul a dit :

Je vois que @TheArchitect n'a pas fait dans la dentelle au niveau des explications 😅

Pour l'instant, j'essaie de contenir le coût du forum autour de 200€ à 300€/mois (serveur, nom de domaine, licence, IP, serveur mail, etc) pour des adhésions/dons qui dépassent rarement 1000€/an. Enfin bref, on réfléchit aux solutions !

Qui supporte la différence entre les 2500/3500€ annuels et les contributions volontaires ?

il y a 23 minutes, William21 a dit :

Qui supporte la différence entre les 2500/3500€ annuels et les contributions volontaires ?

Moi.