phpBB est lent ou met plusieurs secondes à publier un message : trouver la cause et accélérer le forum
Votre forum phpBB semble fonctionner normalement, mais certaines actions deviennent soudainement très lentes ?
Vous cliquez sur Envoyer pour publier un nouveau sujet ou une réponse, puis vous devez attendre 5, 10, 15 secondes ou davantage avant que le message soit réellement publié ?
Ou peut-être que l’ensemble du forum est devenu progressivement plus lent, alors qu’aucune modification évidente ne semble expliquer ce changement ?
Ce type de problème peut être difficile à diagnostiquer, car la lenteur visible n’indique pas directement sa véritable origine.
Elle peut venir de nombreux éléments :
[]l’envoi des e-mails ;
[]les notifications ;
[]les tâches cron ;
[]une extension ;
[]une table de base de données devenue anormalement volumineuse ;
[]une requête SQL lente ;
[]PHP ;
[]MariaDB ou MySQL ;
[]PHP-FPM ;
[]le serveur Web ;
[]un stockage trop lent ;
[]un manque de mémoire ;
[]une charge CPU anormale ;
[]des robots qui sollicitent excessivement le forum ;ou plusieurs de ces éléments en même temps.
Le but de ce guide n’est donc pas de donner une commande magique censée accélérer tous les forums.
Le but est de répondre méthodiquement à une question beaucoup plus importante :
Quelle partie de phpBB est réellement lente, et pourquoi ?
1. Commencez par identifier précisément ce qui est lent
Dire simplement :
Mon forum est lent.
ne suffit pas pour établir un diagnostic.
Il faut commencer par déterminer quelle action précise provoque la lenteur.
Testez séparément :
[]l’accueil du forum ;
[]l’ouverture d’un forum ;
[]l’ouverture d’un sujet ;
[]la création d’un nouveau sujet ;
[]l’ajout d’une réponse ;
[]la modification d’un message existant ;
[]l’envoi d’un message privé ;
[]l’accès au panneau d’administration ;une action dans le panneau d’administration.
Chronométrez approximativement chaque opération.
Par exemple :
Code : Tout sélectionner
Accueil : moins d’une seconde
Ouverture d’un forum : moins d’une seconde
Ouverture d’un sujet : moins d’une seconde
Nouveau sujet : 8 secondes
Réponse : 9 secondes
Modification d’un message : 1 seconde
Message privé : 1 seconde
Cette comparaison est extrêmement importante.
Dans cet exemple, le serveur n’est probablement pas lent de manière générale.
Le symptôme indique plutôt que quelque chose exécuté au moment de la publication ralentit phpBB.
À l’inverse, si l’accueil, les forums, les sujets et le PCA sont tous lents, il faut élargir le diagnostic au serveur, à PHP, à la base de données ou à un traitement global.
2. Comprendre ce qui se passe lorsque vous publiez un message
Lorsqu’un utilisateur clique sur Envoyer, phpBB ne se contente pas forcément d’ajouter le texte du message dans la base de données.
Selon la configuration du forum, phpBB peut également devoir :
[]enregistrer le message ;
[]mettre à jour le sujet ;
[]mettre à jour différents compteurs ;
[]mettre à jour les informations du forum ;
[]traiter les abonnements ;
[]créer des notifications ;
[]préparer des notifications par e-mail ;
[]mettre à jour différents états de lecture ou de suivi ;
[]exécuter des événements utilisés par des extensions ;
[]déclencher ou planifier certaines tâches périodiques.
Cela explique pourquoi un forum peut être extrêmement rapide en consultation, tout en devenant lent uniquement lorsqu’un utilisateur publie quelque chose.
Cette différence n’est pas un détail.
C’est déjà un élément du diagnostic.
3. Ne commencez jamais par supprimer des données
Lorsqu’un administrateur découvre une table de plusieurs centaines de mégaoctets ou de plusieurs millions de lignes, la première réaction peut être de chercher une commande permettant de la vider.
C’est précisément ce qu’il faut éviter.
Ne lancez jamais au hasard des opérations comme :
Code : Tout sélectionner
TRUNCATE TABLE …
DELETE FROM …
DROP TABLE …
Ne videz pas non plus manuellement les tables de sessions, de notifications ou de suivi simplement parce qu’elles vous paraissent trop importantes.
Une table volumineuse n’est pas automatiquement une table défectueuse.
La bonne méthode est :
[]mesurer ;
[]identifier ;
[]comprendre ;
[]sauvegarder ;corriger uniquement lorsque la cause est connue.
Une suppression faite au hasard peut faire disparaître temporairement un symptôme sans résoudre sa cause.
Elle peut également supprimer des données nécessaires au fonctionnement normal du forum.
4. Premier suspect lorsque seule la publication est lente : les e-mails
L’envoi d’e-mails est une cause classique de lenteur au moment de publier un message.
Lorsqu’un nouveau message est publié, phpBB peut devoir traiter des notifications concernant notamment :
[]les utilisateurs abonnés au sujet ;
[]les utilisateurs surveillant le forum ;certaines notifications configurées individuellement par les membres.
Si le serveur de messagerie répond lentement, si la connexion SMTP rencontre un problème ou si un traitement lié aux notifications prend trop de temps, l’utilisateur peut avoir l’impression que phpBB lui-même est lent.
Test simple de diagnostic
Désactivez temporairement l’envoi des e-mails dans le PCA, uniquement le temps d’effectuer un test.
Publiez ensuite exactement le même type de message.
Comparez les résultats.
Par exemple :
Code : Tout sélectionner
E-mails activés : 9 secondes
E-mails désactivés : 1 seconde
Ce résultat ne signifie pas :
Je dois laisser les e-mails désactivés.
Il signifie :
La lenteur semble liée à la chaîne d’envoi des e-mails ou au traitement des notifications.
Vous savez désormais où concentrer le diagnostic.
Il faudra alors examiner notamment :
[]la configuration SMTP ;
[]les délais de connexion au serveur SMTP ;
[]la fonction d’envoi utilisée ;
[]les erreurs de connexion ;
[]les notifications ;
[]les tâches cron ;les journaux d’erreurs.
Si votre problème concerne spécifiquement les e-mails, consultez également le guide consacré au diagnostic SMTP disponible dans cette même rubrique d’aide de phpBB Lab.
5. Vérifiez le fonctionnement du cron phpBB
phpBB utilise des tâches périodiques pour effectuer certains traitements d’entretien.
Selon la configuration, ces tâches peuvent être déclenchées par phpBB lui-même ou confiées au cron du système.
Sur un hébergement mutualisé, le fonctionnement automatique de phpBB est généralement utilisé.
Sur un VPS ou un serveur dédié, un administrateur peut décider de faire exécuter ces tâches directement par le système.
Cette configuration peut être parfaitement valable.
Mais il existe un piège important :
activer dans phpBB l’utilisation du cron système sans avoir réellement configuré ce cron sur le serveur.
Dans cette situation, certaines tâches périodiques peuvent ne plus être exécutées normalement.
Des traitements ou données temporaires peuvent alors s’accumuler progressivement.
6. Tester manuellement le cron avec SSH
Si vous administrez votre propre serveur et disposez d’un accès SSH, placez-vous dans la racine de votre installation phpBB.
Vous pouvez ensuite lancer :
Code : Tout sélectionner
php bin/phpbbcli.php cron:run
Cette commande sert d’abord au diagnostic.
Observez ce qui se passe.
[]La commande se termine-t-elle normalement ?
[]Une erreur apparaît-elle ?
[]L’exécution prend-elle énormément de temps ?
[]Certaines données sont-elles nettoyées ?
[]La taille de certaines tables évolue-t-elle ?
[]Les publications deviennent-elles plus rapides après l’exécution ?
Si une simple exécution manuelle du cron améliore brutalement la situation, ne vous contentez pas de relancer cette commande tous les jours manuellement.
Cherchez pourquoi l’exécution automatique ne fonctionnait plus.
7. Vérifiez le cron après un changement de version PHP
Un problème fréquent sur un serveur administré manuellement est le cron qui fonctionnait correctement avant une mise à jour de PHP et qui ne fonctionne plus ensuite.
Imaginez par exemple :
Code : Tout sélectionner
Cron configuré
↓
Le cron utilise explicitement une ancienne version de PHP
↓
PHP est mis à jour sur le serveur
↓
L’ancien exécutable disparaît ou n’est plus utilisé
↓
Le cron phpBB ne s’exécute plus
Le forum peut pourtant continuer à fonctionner.
Le problème peut donc rester invisible pendant plusieurs jours ou plusieurs semaines.
Après une modification importante du serveur, vérifiez notamment :
[]la version de PHP utilisée par le Web ;
[]la version de PHP utilisée en ligne de commande ;
[]le chemin utilisé par votre tâche cron ;
[]les journaux du cron système ;le résultat d’une exécution manuelle.
8. Votre base de données grossit-elle anormalement ?
Une base de données qui grossit n’indique pas automatiquement un problème.
Un forum ancien et très actif peut naturellement posséder une base importante.
Il faut comparer sa croissance avec l’activité réelle du site.
Par exemple :
Code : Tout sélectionner
Lundi : 120 Mo
Mardi : 260 Mo
Mercredi : 600 Mo
Jeudi : 1,4 Go
Si votre forum reçoit simultanément plusieurs centaines de milliers de nouveaux messages, cette augmentation peut avoir une explication évidente.
Mais si seulement quelques messages ont été publiés, il faut chercher quelle table est responsable de cette croissance.
9. Identifiez la table qui grossit
Ne regardez pas uniquement la taille totale de la base.
Cherchez quelle table augmente.
Selon le symptôme rencontré, certaines tables peuvent notamment mériter votre attention :
Code : Tout sélectionner
phpbb_sessions
phpbb_notifications phpbb_notification_emails
phpbb_topics_track
phpbb_forums_track
phpbb_topics_posted
phpbb_posts
phpbb_topics
Attention :
Le préfixe
Code : Tout sélectionner
phpbb_n’est qu’un exemple.
Votre installation peut utiliser un autre préfixe.
Et encore une fois :
une table importante n’est pas forcément anormale.
Un gros forum peut légitimement contenir énormément de données.
Ce qui compte est le rapport entre :
[]la taille ;
[]le nombre de lignes ;
[]l’activité réelle du forum ;
[]et surtout la vitesse à laquelle cette table grossit.
10. Mesurez avant de supprimer
Si vous avez accès à MariaDB ou MySQL, commencez par effectuer uniquement des lectures.
Exemple :
Code : Tout sélectionner
SELECT COUNT(*) FROM phpbb_sessions;
Pour les notifications :
Code : Tout sélectionner
SELECT COUNT(*) FROM phpbb_notifications;
Et si la table existe sur votre installation :
Code : Tout sélectionner
SELECT COUNT(*) FROM phpbb_notification_emails;
Ces requêtes permettent simplement de compter les lignes.
Elles ne suppriment rien.
Notez les résultats et recommencez éventuellement le test plus tard.
Par exemple :
Code : Tout sélectionner
10h00 : 48 000 lignes
12h00 : 52 000 lignes
14h00 : 171 000 lignes
16h00 : 420 000 lignes
Une évolution de ce type est beaucoup plus intéressante pour établir un diagnostic que la simple phrase :
Ma table contient beaucoup de lignes.
11. Surveillez particulièrement les sessions
La table des sessions est utilisée par phpBB pour gérer les sessions des utilisateurs.
Son nombre de lignes varie notamment selon :
[]les membres connectés ;
[]les invités ;
[]les robots ;
[]la fréquentation générale ;
[]la durée des sessions ;
[]le nettoyage correct des anciennes sessions.
Une augmentation importante pendant un pic de fréquentation peut donc être normale.
En revanche, une accumulation massive et permanente doit être étudiée.
Elle peut notamment être liée à :
[]un nettoyage périodique qui ne s’exécute plus ;
[]un problème de cron ;
[]une activité robotisée extrêmement importante ;
[]des robots mal identifiés ;un comportement inhabituel de certaines requêtes.
Ne videz pas immédiatement la table.
Cherchez d’abord pourquoi les anciennes données ne disparaissent pas comme prévu.
12. Pensez également aux robots
Un forum peut être peu actif humainement et pourtant recevoir énormément de requêtes.
Les robots et crawlers peuvent :
[]ouvrir énormément de pages ;
[]créer de nombreuses sessions ;
[]parcourir des URL très anciennes ;
[]solliciter PHP ;
[]solliciter MariaDB ou MySQL ;
[]augmenter fortement le nombre de requêtes ;remplir rapidement certains journaux.
Sur un VPS, consultez les journaux d’accès du serveur Web.
Cherchez notamment :
[]les adresses IP qui génèrent énormément de requêtes ;
[]les User-Agent ;
[]les URL appelées ;
[]le rythme des requêtes.
Attention cependant à ne pas bloquer indistinctement tous les robots.
Les moteurs de recherche légitimes ont besoin d’explorer votre forum pour l’indexer.
L’objectif est de distinguer un crawl normal d’un comportement excessif.
13. Une extension peut-elle ralentir la publication ?
Oui.
Une extension phpBB peut écouter un événement déclenché lorsque vous publiez un message.
Elle peut alors effectuer :
[]une requête SQL ;
[]un traitement du texte ;
[]une analyse ;
[]une opération sur un fichier ;
[]une notification ;
[]un appel réseau ;une connexion vers un service externe.
Une seule extension peut donc rendre la publication très lente alors que tout le reste du forum fonctionne normalement.
La bonne méthode consiste à tester progressivement.
[]Notez les extensions actives.
[]Commencez par celles installées ou mises à jour récemment.
[]Désactivez une extension suspecte.
[]Purgez le cache si nécessaire.
[]Effectuez exactement le même test de publication.
[]Mesurez le résultat.Réactivez l’extension et vérifiez si la lenteur revient.
Exemple :
Code : Tout sélectionner
Extension active : 8,6 secondes
Extension désactivée : 1,2 seconde
Extension réactivée : 8,5 secondes
Ce test devient alors reproductible.
Vous ne savez pas encore forcément pourquoi l’extension est lente, mais vous avez isolé précisément le composant responsable.
14. Attention aux extensions utilisant des services externes
Une extension peut fonctionner parfaitement pendant des mois puis commencer soudainement à ralentir phpBB sans qu’aucun fichier du forum n’ait été modifié.
Pourquoi ?
Parce qu’elle dépend peut-être d’un service extérieur.
Par exemple :
[]une API ;
[]un service antispam ;
[]un webhook ;
[]un serveur distant ;
[]un outil de statistiques ;
[]une intelligence artificielle ;
[]un serveur de licence ;
[]un système externe de notification.
Supposons qu’une extension appelle une API externe au moment de la publication.
Habituellement :
Code : Tout sélectionner
Réponse API : 0,2 seconde
Puis le service rencontre un problème :
Code : Tout sélectionner
Réponse API : 8 secondes
Votre publication peut elle aussi prendre environ 8 secondes.
Dans ce cas, acheter un serveur deux fois plus puissant ne résoudra probablement rien.
Le problème est le traitement distant exécuté au mauvais moment.
15. Consultez les journaux d’erreurs
Une lenteur peut cacher une erreur répétée.
Avant de modifier PHP, MariaDB ou votre serveur, consultez les journaux disponibles.
Dans phpBB :
PCA → Maintenance → Journal des erreurs
Sur un hébergement mutualisé, consultez également les journaux proposés par votre hébergeur.
Sur un VPS, examinez selon votre configuration :
[]les logs du serveur Web ;
[]les logs PHP ;
[]les logs PHP-FPM ;
[]les logs MariaDB ou MySQL ;les logs du cron.
Cherchez notamment des erreurs contenant des termes comme :
Code : Tout sélectionner
PHP error
PHP warning
Fatal error
timeout
database error
SMTP
connection refused
memory exhausted
maximum execution time
Une opération qui échoue puis attend un délai d’expiration peut ajouter plusieurs secondes à chaque publication.
16. Vérifiez les ressources du serveur sans tirer de conclusion trop rapidement
Sur un VPS, observez également les ressources disponibles.
Notamment :
[]CPU ;
[]mémoire vive ;
[]swap ;
[]charge système ;
[]stockage ;
[]entrées/sorties disque ;
[]processus PHP ;
[]PHP-FPM ;MariaDB ou MySQL.
Mais attention :
un CPU très utilisé ne signifie pas automatiquement que le serveur est trop faible.
Une requête SQL mal adaptée ou une extension effectuant un traitement excessif peut utiliser énormément de ressources, même sur un serveur très puissant.
Inversement, un forum correctement configuré peut fonctionner parfaitement sur une infrastructure relativement modeste.
Il faut donc observer les ressources au moment exact où vous reproduisez le problème.
17. Si tout le forum est lent
Si toutes les pages sont lentes, élargissez le diagnostic.
Testez :
[]l’accueil ;
[]les forums ;
[]les sujets ;
[]la recherche ;
[]les profils ;
[]le PCA ;la publication.
Si tout ralentit simultanément, vérifiez notamment :
[]PHP ;
[]PHP-FPM ;
[]OPcache ;
[]MariaDB ou MySQL ;
[]les ressources mémoire ;
[]le CPU ;
[]les entrées/sorties disque ;
[]l’espace disque disponible ;
[]les extensions qui agissent sur toutes les pages ;
[]le serveur Web ;
[]les tâches lourdes exécutées en parallèle ;
[]les sauvegardes automatiques ;les appels vers des services externes.
18. Si seule la publication est lente
Si le forum est rapide partout sauf lorsque vous cliquez sur Envoyer, concentrez-vous d’abord sur ce qui est exécuté pendant cette action.
Ordre de recherche raisonnable :
[]e-mails ;
[]notifications ; []cron ;
[]extensions intervenant lors de la publication ;
[]appels vers des services externes ;
[]requêtes SQL exécutées lors de l’envoi ;
[]tables de suivi ou de notifications très volumineuses ;
[]ressources serveur pendant l’opération.
Ne commencez pas par modifier toute la configuration de MariaDB si votre accueil s’affiche instantanément et que seule la publication prend dix secondes.
Le symptôme vous indique déjà dans quelle direction chercher.
19. Comparez plusieurs forums
Si votre installation contient plusieurs forums, effectuez le même test dans différents endroits.
Par exemple :
Code : Tout sélectionner
Forum A : réponse en 1 seconde
Forum B : réponse en 1 seconde
Forum C : réponse en 11 secondes
Cette différence est très intéressante.
Elle indique que le problème pourrait dépendre :
[]du forum concerné ;
[]de ses abonnements ;
[]de ses notifications ;
[]du volume de données ;
[]de certains sujets ;
[]ou d’une extension appliquant une logique différente selon le forum.
Comparez également :
[]un nouveau sujet ;
[]une réponse ;
[]une modification ;
[]un petit sujet ;un très gros sujet.
20. Sauvegardez avant toute maintenance importante de la base
Lire et mesurer des données n’est pas la même chose que les modifier.
Avant toute opération comme :
[]une suppression massive ;
[]une reconstruction importante ;
[]une réparation ;
[]une modification d’index ;
[]une conversion de moteur ;
[]une opération SQL importante ;
effectuez une sauvegarde complète de la base de données.
Et si possible, assurez-vous également de savoir comment cette sauvegarde pourrait être restaurée.
Une sauvegarde que personne ne sait restaurer offre une sécurité beaucoup plus limitée qu’on ne le pense.
21. Ne modifiez jamais dix paramètres en même temps
C’est une règle fondamentale du diagnostic.
Mauvaise méthode :
Code : Tout sélectionner
Désactiver SMTP
Modifier cron
Changer PHP
Modifier MariaDB
Vider plusieurs tables
Désactiver cinq extensions
Redémarrer le serveur
Tester
Imaginons que le forum redevienne rapide.
Quelle était la cause ?
Vous n’en savez rien.
Bonne méthode :
Code : Tout sélectionner
Mesurer
↓
Modifier une seule chose
↓
Tester
↓
Noter le résultat
↓
Revenir en arrière si nécessaire
↓
Passer au test suivant
Ainsi, chaque étape apporte une information exploitable.
22. Exemple complet de diagnostic
Prenons un forum présentant les résultats suivants :
Code : Tout sélectionner
Accueil : 0,4 seconde
Ouverture d’un forum : 0,5 seconde
Lecture d’un sujet : 0,5 seconde
Modification d’un message : 0,8 seconde
Publication d’une réponse : 11 secondes
Le serveur ne semble donc pas lent en permanence.
Premier test : e-mails
Les e-mails sont temporairement désactivés.
Nouveau résultat :
Code : Tout sélectionner
Publication : 1 seconde
La piste e-mail ou notification devient prioritaire.
Il faut alors diagnostiquer SMTP, les notifications et les traitements associés.
Autre scénario
E-mails désactivés :
Code : Tout sélectionner
Publication : toujours 11 secondes
Les e-mails ne semblent donc pas être la cause principale.
Deuxième test : cron
Exécution manuelle :
Code : Tout sélectionner
php bin/phpbbcli.php cron:run
Puis nouveau test :
Code : Tout sélectionner
Avant cron : 11 secondes
Après cron : 1,7 seconde
Il faut maintenant comprendre pourquoi les tâches périodiques ne s’exécutaient plus normalement.
Troisième scénario : extension
Code : Tout sélectionner
Extension active : 11 secondes
Extension désactivée : 1 seconde
Extension réactivée : 10,8 secondes
L’extension devient alors le principal suspect.
Vous avez transformé :
Mon phpBB est lent.
en :
Une opération exécutée par cette extension lors de la publication ajoute environ dix secondes au traitement.
C’est cela, un diagnostic utile.
23. Tableau de diagnostic rapide
Toutes les pages sont lentes :
Code : Tout sélectionner
PHP
PHP-FPM
MariaDB / MySQL
CPU
mémoire
I/O disque
extension globale
serveur Web
Seule la publication est lente :
Code : Tout sélectionner
e-mails
notifications
cron
extensions liées à la publication
appels externes
requêtes exécutées à l’envoi
Un seul forum est lent :
Code : Tout sélectionner
données propres au forum
abonnements
notifications
volume de sujets
extension conditionnelle
La base grossit anormalement :
Code : Tout sélectionner
identifier la table
mesurer son évolution
vérifier cron
vérifier sessions
vérifier notifications
vérifier robots
comparer avec l’activité réelle
24. Quelles informations fournir lorsque vous demandez de l’aide ?
Si vous ouvrez un sujet de support concernant des lenteurs, fournissez directement les informations suivantes.
Versions
Code : Tout sélectionner
Version phpBB :
Version PHP :
MariaDB ou MySQL :
Version MariaDB/MySQL :
Type d’hébergement
Code : Tout sélectionner
Mutualisé / VPS / serveur dédié :
Taille approximative
Code : Tout sélectionner
Taille de la base :
Nombre de messages :
Nombre de sujets :
Nombre de membres :
Mesures
Code : Tout sélectionner
Accueil :
Ouverture d’un forum :
Lecture d’un sujet :
Publication :
Modification :
Message privé :
E-mails
Code : Tout sélectionner
E-mails activés : oui/non
SMTP utilisé : oui/non
La lenteur disparaît avec les e-mails temporairement désactivés : oui/non/non testé
Cron
Code : Tout sélectionner
Cron système activé dans phpBB : oui/non/inconnu
Cron réellement configuré sur le serveur : oui/non/inconnu
Exécution manuelle testée : oui/non
Résultat :
Extensions
Indiquez les extensions installées, en particulier celles récemment ajoutées ou mises à jour.
Changements récents
Précisez si le problème est apparu après :
[]une mise à jour phpBB ;
[]une mise à jour PHP ;
[]un changement de serveur ;
[]une migration ;
[]une nouvelle extension ;
[]une mise à jour d’extension ;
[]une modification SMTP ;
[]une modification MariaDB/MySQL ;un changement d’hébergeur.
Logs
Copiez uniquement les erreurs pertinentes.
Ne publiez jamais :
[]un mot de passe ;
[]un mot de passe SMTP ;
[]un mot de passe MariaDB ou MySQL ;
[]une clé API ;
[]une clé privée ;
[]un secret ;
[]un cookie de session ;
[]un jeton d’authentification.
25. Checklist de diagnostic
[]J’ai identifié exactement quelle action est lente.
[]J’ai comparé consultation, publication, modification et messages privés.
[]J’ai mesuré approximativement les temps.
[]J’ai consulté le journal d’erreurs de phpBB.
[]J’ai consulté les logs serveur si j’y ai accès.
[]J’ai testé temporairement l’impact des e-mails.
[]J’ai vérifié la configuration du cron.
[]J’ai vérifié qu’un cron système activé est réellement configuré.
[]J’ai testé une exécution manuelle du cron si j’ai accès à SSH.
[]J’ai vérifié les extensions récemment installées ou mises à jour.
[]J’ai comparé plusieurs forums.
[]J’ai identifié les tables qui grossissent anormalement.
[]J’ai mesuré leur évolution.
[]Je n’ai supprimé aucune donnée SQL au hasard.
[]J’ai vérifié l’activité des robots si les sessions augmentent fortement.
[]J’ai noté les changements récents du serveur.J’ai une sauvegarde avant toute opération importante.
À retenir
Un forum phpBB lent n’est pas forcément un forum hébergé sur un serveur trop faible.
Et lorsqu’un forum est parfaitement rapide jusqu’au moment où vous cliquez sur Envoyer, cette différence constitue déjà un indice important.
Commencez toujours par répondre à quatre questions :
Code : Tout sélectionner
Qu’est-ce qui est lent ?
Depuis quand ?
Qu’est-ce qui a changé ?
Quelle action déclenche précisément la lenteur ?
Puis procédez méthodiquement :
Code : Tout sélectionner
E-mails
↓
Notifications
↓
Cron
↓
Extensions
↓
Base de données
↓
PHP
↓
Serveur
Mesurez avant de modifier.
Ne changez qu’une chose à la fois.
Ne supprimez jamais des données simplement parce qu’une table vous paraît trop grosse.
Un bon diagnostic ne consiste pas uniquement à faire disparaître temporairement la lenteur.
Il doit permettre de comprendre pourquoi elle existait, afin de corriger sa véritable cause et d’éviter qu’elle revienne.