par Kellogs » 10 nov. 2014, 09:12
Bonjour à tous,
Vous l'avez probablement noté, le forum était inaccessible dimanche 9 Novembre durant l'après-midi.
Et cela n'est pas la première fois que cela arrive !
Pourant, le nombre maximum de visiteurs n'est que de 224 le 26 Sep 2014.
Pourriez-vous contacter l'administrateur pour lui faire part de mes remarques :
ayant été administrateur de site PhpBB avec un fort trafic, voici ce qui peut se passer :
* Chaque page du forum génère des dizaines (voire des centaines de requêtes SQL). MySQL doit exécuter des milliers de requêtes par seconde.
* MySQL est débordé par le nombre de requêtes SQL et commence à fonctionner lentement. Si 1000 requêtes passent en 1 seconde, en envoyer 10000 dure 10 secondes, voire plus. Chaque requête s'exécute lentement, c'est normal. Ce qui pose problème dans PhpBB, c'est que quelques requêtes sont gourmandes, notamment les recherches en texte plein. Si dans le lot, une requête s'exécute en 1 seconde, elle freine toutes les autres, qui attendent au portillon.
* La tentation de l'administrateur est de mettre du cache partout : MySQL et PHP.
* Mais ce cache ne sert à rien et même aggrave la situation, car les requêtes MySQL gourmandes (recherche texte plein) sont quand même lancées et PHP doit conserver les données en mémoire (threads). Il en résulte une baisse de la mémoire RAM disponible.
* A un certain point, la base de données MySQL elle-même manque de mémoire RAM et c'est l'effondrement du site.
LA solution consiste à :
* Machine dédiée (off course). Si ce n'est pas le cas, on peut arrêter là, le site ne fonctionnera JAMAIS.
* Utiliser des disques SSD pour stocker la base de données MySQL. Fondamental car un disque SSD est 100 fois plus rapide qu'un disque traditionnel.
* Limiter au maximum l'utilisation de mémoire cache dans la base de données et dans PHP. Dès lors qu'on utilise des SSD, on n'a plus besoin de cache (inutile).
* Logger toutes les requêtes SQL lentes (>100 millisecondes) et identifier à quel moment le site devient encombré et pourquoi.
* Bien compartimenter la mémoire entre la base de données et les threads Apache. Rien en cache, c'est de la perte de temps sur un site à fort fréquentation.
Sous PostgreSQL, j'avais effectué ce travail et je tournais avec une version modifiée de PhpBB qui acceptait 5.000 utilisateurs simultanés sur une seule machine, sans aucun cache.
A l'avenir, il faut également réfléchir à la migration de MySQL vers PostgreSQL. MySQL est une base de données de débutants, qui ne tient pas la route et dont on ne peut pas administrer les performances (mémoire, rapidité d'exécution, etc ...). C'est de la daube. Il faut donc réfléchir à une migration vers PostgreSQL.
Si vous faites de la mécanique, vous devez savoir que certaines architectures ne fonctionnent pas à partir de 250.000 km. Avec MySQL, c'est pareil, à éviter à tout prix.
Bonjour à tous,
Vous l'avez probablement noté, le forum était inaccessible dimanche 9 Novembre durant l'après-midi.
Et cela n'est pas la première fois que cela arrive !
Pourant, le nombre maximum de visiteurs n'est que de 224 le 26 Sep 2014.
Pourriez-vous contacter l'administrateur pour lui faire part de mes remarques :
ayant été administrateur de site PhpBB avec un fort trafic, voici ce qui peut se passer :
* Chaque page du forum génère des dizaines (voire des centaines de requêtes SQL). MySQL doit exécuter des milliers de requêtes par seconde.
* MySQL est débordé par le nombre de requêtes SQL et commence à fonctionner lentement. Si 1000 requêtes passent en 1 seconde, en envoyer 10000 dure 10 secondes, voire plus. Chaque requête s'exécute lentement, c'est normal. Ce qui pose problème dans PhpBB, c'est que quelques requêtes sont gourmandes, notamment les recherches en texte plein. Si dans le lot, une requête s'exécute en 1 seconde, elle freine toutes les autres, qui attendent au portillon.
* La tentation de l'administrateur est de mettre du cache partout : MySQL et PHP.
* Mais ce cache ne sert à rien et même aggrave la situation, car les requêtes MySQL gourmandes (recherche texte plein) sont quand même lancées et PHP doit conserver les données en mémoire (threads). Il en résulte une baisse de la mémoire RAM disponible.
* A un certain point, la base de données MySQL elle-même manque de mémoire RAM et c'est l'effondrement du site.
LA solution consiste à :
* Machine dédiée (off course). Si ce n'est pas le cas, on peut arrêter là, le site ne fonctionnera JAMAIS.
* Utiliser des disques SSD pour stocker la base de données MySQL. Fondamental car un disque SSD est 100 fois plus rapide qu'un disque traditionnel.
* Limiter au maximum l'utilisation de mémoire cache dans la base de données et dans PHP. Dès lors qu'on utilise des SSD, on n'a plus besoin de cache (inutile).
* Logger toutes les requêtes SQL lentes (>100 millisecondes) et identifier à quel moment le site devient encombré et pourquoi.
* Bien compartimenter la mémoire entre la base de données et les threads Apache. Rien en cache, c'est de la perte de temps sur un site à fort fréquentation.
Sous PostgreSQL, j'avais effectué ce travail et je tournais avec une version modifiée de PhpBB qui acceptait 5.000 utilisateurs simultanés sur une seule machine, sans aucun cache.
A l'avenir, il faut également réfléchir à la migration de MySQL vers PostgreSQL. MySQL est une base de données de débutants, qui ne tient pas la route et dont on ne peut pas administrer les performances (mémoire, rapidité d'exécution, etc ...). C'est de la daube. Il faut donc réfléchir à une migration vers PostgreSQL.
Si vous faites de la mécanique, vous devez savoir que certaines architectures ne fonctionnent pas à partir de 250.000 km. Avec MySQL, c'est pareil, à éviter à tout prix.
