Leçons apprises : optimisation MySQL/MariaDB avec Dolibarr sans casser l’existant

Optimiser une base de données Dolibarr est un exercice délicat. L’objectif est double : accélérer les temps de réponse et réduire la charge serveur, sans jamais compromettre la stabilité et l’intégrité des données existantes. Après des années d’interventions sur des installations critiques, voici la méthodologie et les leçons apprises pour y parvenir.

1. Le mantra : Observer, Comprendre, Agir (sans précipitation)

La première erreur est de vouloir appliquer des recettes génériques ("augmentez le innodb_buffer_pool_size !"). Dolibarr, comme tout ERP, a un schéma de données et des patterns d’usage très spécifiques.

  • Leçon n°1 : L’optimisation commence par la métrique. Sans mesure avant/après, vous optimisez dans le vide.

  • Outil indispensable : Le slow_query_log de MySQL/MariaDB. Activez-le (long_query_time = 1 seconde par défaut) pendant une période représentative (une semaine tipo). C’est votre table des diagnostics.

  • Regardez aussi les logs Dolibarr : les erreurs PHP et les warnings de performance peuvent indiquer des requêtes problématiques.

2. La phase d’analyse :Identifier les vrais goulets d’étranglement

Analyser le slow_query_log avec un outil comme mysqldumpslow ou, mieux, pt-query-digest (de Percona Toolkit) vous donnera les requêtes les plus lentes et les plus fréquentes.

Les tables Dolibarr les plus souvent en cause :

  • llx_actioncomm : La table des agendas et événements, qui peut devenir énorme et mal indexée si elle contient des millions de lignes sans entretien.

  • llx_product / llx_societe : Structures complexes avec de nombreuses jointures (catégories, prix, contacts, adresses).

  • Tables de logs (llx_cron_log, llx_actioncomm pour l’historique) : Elles grossissent exponentiellement.

  • Tables de modules externes/modifiés : Un module mal conçu peut ajouter des tables sans index pertinents.

Leçon n°2 : Ce n’est pas toujours une question d’index. Une requête lente peut être due à :

  1. Un mauvais schéma (une table qui devrait être partitionnée).

  2. Des données obsolètes (des millions de logs de 2018 toujours en base).

  3. Une configuration MySQL inadéquate (taille de buffer trop petite pour la charge).

  4. Une requête mal écrite dans un module personnalisé ou une version spécifique de Dolibarr.

3. La méthodologie "sans casser l’existant" : un protocole en 5 étapes

Étape 1 : Sauvegarde & Rollback (Phase NON-NÉGOCIABLE)

  • Sauvegarde complète de la base (mysqldump ou mydumper/myloader pour les grosses bases) avant toute manipulation.

  • Documentez précisément ce que vous allez changer (fichier de config, requête SQL d’ajout d’index, commande d’optimisation de table).

  • Ayez un plan de retour arrière (restauration de la sauvegarde, annulation de l’index ajouté).

Étape 2 : Test en environnement pré-production (ISOLATION)

  • Jamais de test direct sur la production.

  • Clonez la base de production (un dump importé sur un serveur de test identique) et le serveur web.

  • Rejouez la charge (ou une simulation réaliste) avec un outil comme Apache JMeter ou Siege.

  • Mesurez lestemps de réponse et la consommation avec SHOW PROCESSLIST, performance_schema, ou des outils comme Percona Monitoring and Management (PMM).

Étape 3 : Optimisations "à impact zéro ou positif"

Commencez par les actions les moins risquées, souvent les plus payantes :

  • Nettoyage des données mortes (DATA PURGING) :

    • Supprimer les anciens logs (cron_log, actioncomm marqués comme "annulés" ou très anciens). Toujours archiver avant de supprimer !

    • Vider la corbeille (llx_bookmark peut en accumuler).

    • Leçon n°3 : Mettre en place un cron job de purge paramétrable. Dans Dolibarr, c’est possible via le module "Divers" -> "Outils de maintenance".

  • Optimisation des tables (table maintenance) :

    • OPTIMIZE TABLE llx_actioncomm; (attention : peut verrouiller la table, à faire en période de faible activité). Plus sûr pour InnoDB : ALTER TABLE llx_actioncom ENGINE=InnoDB;

    • Pour les tables avec beaucoup de DELETE, cela reconstruit les index et défragmente.

  • Analyse et ajustement des INDEX existants :

    • Utilisez EXPLAIN [VOTRE REQUÊTE LENTE] pour voir le plan d’exécution.

    • Ajoutez des index composites ciblant les clauses WHERE, JOIN et ORDER BY des requêtes lentes identifiées. Ne recréez pas la roue : vérifiez d’abord si un index n’existe pas déjà (cherchez dans SHOW INDEX FROM ma_table).

    • Exemple typique Dolibarr : Une recherche avancée sur les sociétés (societe) par pays/ville/état peut nécessiter un index sur (country, town, state).

Étape 4 : Optimisations structurelles / configuration MySQL (IMPACT MOYEN)

  • Ajustement des variables my.cnf :

    • innodb_buffer_pool_size : Doit être ~70-80% de la RAM totale sur un serveur dédié DB. C’est le paramètre le plus important pour InnoDB. Augmentez-le progressivement.

    • innodb_log_file_size : Plus il est grand (ex: 512M-1G), mieux InnoDB gère les écritures, mais redémarrage requis.

    • query_cache_type / query_cache_size : À désactiver (0) dans les versions modernes de MySQL/MariaDB et Dolibarr (sauf cas très spécifiques de charges répétitives identiques). Il devient souvent un goulet d’étranglement.

    • max_connections : Ajuster selon le nombre réel d’utilisateurs simultanés et le comportement du pool de connexions (PHP-FPM).

    • Leçon n°4 : Modifiez une variable à la fois, redémarrez, et monitorez (SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool%').

  • Passage à MariaDB (si pertinent) : MariaDB offre parfois de meilleures performances sur des charges spécifiques (colonnes virtual, optimisations de l’optimiseur). Testez d’abord en pré-prod.

Étape 5 : Optimisations applicatives (en dernier recours)

  • Si une requête est fondamentalement mauvaise (ex: SELECT * sur une grosse table sans WHERE), il faut corriger le code PHP de Dolibarr ou du module concerné.

  • Extraits à optimiser :

    • Les listes d’éléments (produits, contacts) qui chargent tout sans pagination (LIMIT).

    • Les calculs de statistiques en temps réel sur des volumes importants (préférez des tables de synthèse pré-calculées par cron).

  • Leçon n°5 : Collaborer avec le développeur du module ou patcher proprement le code Dolibarr (hierarchy/htdocs). Ne modifiez jamais le coeur sans un suivi rigoureux des modifications pour les futures montées de version.

4. Checklist de sécurité "Production Ready"

Avant de basculer en production :

  • [ ] Sauvegarde testée (restauration réussie sur un serveur isolé).

  • [ ] Script de rollback prêt (ordre inverse des opérations SQL).

  • [ ] Fenêtre de maintenance planifiée (pour les opérations verrouillantes comme OPTIMIZE ou changement de my.cnf).

  • [ ] Monitoring activé (Grafana + PMM, ou au minimum SHOW ENGINE INNODB STATUS et SHOW PROCESSLIST sous la main).

  • [ ] Équipe informée (qui surveille, qui peut agir en cas de problème).

5. Conclusion : L’optimisation est un cycle, pas un événement

Optimiser Dolibarr sans tout casser repose sur une discipline de fer :

  1. Mesurer avant, pendant, après.

  2. Tester hors production.

  3. Changer par petites touches incrémentales.

  4. Sauvegarder et pouvoir revenir en arrière.

  5. Automatiser le nettoyage (purge des logs) et le monitoring.

Le gain le plus sûr et le moins risqué vient souvent du nettoyage des données historiques et de l’ajout d’index ciblés sur les tables identifiées comme critiques. La configuration MySQL vient ensuite, et enfin, si nécessaire, la correction du code.

Rappel final : La priorité absolue est la disponibilité et l’intégrité des données de l’entreprise. Une base de données 10% plus lente mais infaillible vaut mieux qu’une base ultra-rapide qui perd ou corrompt des données.

En suivant cette approche méthodique, vous transformez l’optimisation de votre Dolibarr d’un acte de bravoure risqué en une procédure d’ingénierie maîtrisée, au bénéfice de la productivité de tous les utilisateurs.

Publications similaires