Une configuration PHP ou base de données ne se copie pas d’un serveur à l’autre. La mémoire disponible, le nombre de workers PHP-FPM, la taille du catalogue, le cache, les modules et le trafic déterminent les réglages utiles. Une valeur trop agressive peut faire tomber le serveur ou masquer une requête lente.
Ce guide donne une méthode de diagnostic applicable à PrestaShop 8 et 9. Les chiffres sont volontairement des points de départ: mesurez avant, modifiez un paramètre à la fois et conservez une procédure de retour arrière.
Commencer par mesurer le problème
Avant toute modification, collectez pendant une période représentative :
- les pages réellement lentes, connectées ou non ;
- le TTFB et le temps de réponse applicatif ;
- les erreurs PHP et les
out of memory; - la consommation CPU, RAM et I/O ;
- les requêtes SQL lentes et leur fréquence ;
- le nombre de processus PHP concurrents.
Une page de catégorie, une recherche et le tunnel de commande sont plus révélateurs qu’une page d’accueil servie depuis un cache. Utilisez les outils de votre hébergeur, les logs serveur et le profiler PrestaShop sur une préproduction lorsque c’est possible.
PHP : régler la capacité avant de chercher des optimisations
Vérifier la version réellement supportée
La compatibilité dépend de la version exacte de PrestaShop et de ses modules. Ne mettez pas à jour PHP seulement parce qu’une version est plus récente. Consultez la documentation et testez d’abord les paiements, transporteurs, synchronisations et tâches planifiées sur une copie de la boutique.
Dimensionner memory_limit et les workers ensemble
Un memory_limit très élevé, combiné à trop de workers PHP-FPM, peut épuiser toute la RAM. L’ordre de travail est :
- mesurer le pic mémoire d’une page lourde ;
- ajouter une marge raisonnable ;
- calculer le nombre maximal de processus compatible avec la RAM disponible ;
- réserver de la mémoire au système, à la base de données et au cache ;
- tester sous charge progressive.
Exemple de point de départ à adapter, jamais de vérité universelle :
; php.ini ou pool PHP-FPM
memory_limit = 512M
max_execution_time = 60
max_input_vars = 10000La valeur 512M est souvent nécessaire pour des imports ou un back-office chargé, mais elle n’est pas un objectif en soi. Si une page consomme cette quantité de mémoire, cherchez le module ou l’opération en cause avant d’augmenter encore la limite.
Activer et contrôler OPcache
OPcache évite de recompiler les scripts PHP à chaque requête. Vérifiez qu’il est actif et surveillez son taux d’utilisation plutôt que de recopier des tailles arbitraires.
opcache.enable = 1
opcache.memory_consumption = 128
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 1Après un déploiement, videz le cache applicatif et vérifiez que les changements de code sont bien pris en compte. Sur un processus de déploiement maîtrisé, validate_timestamps peut être réglé différemment, mais seulement avec une invalidation fiable d’OPcache.
MySQL ou MariaDB : traiter les requêtes avant les paramètres
Un cache de base trop grand ne répare pas une requête sans index. Activez d’abord le journal des requêtes lentes sur un environnement contrôlé ou avec un seuil prudent, puis cherchez :
- les requêtes lentes répétées ;
- les scans complets de tables ;
- les jointures sans index adapté ;
- les modules qui lancent des requêtes à chaque affichage ;
- les tâches d’indexation concurrentes.
Utilisez EXPLAIN sur une requête représentative avant d’ajouter un index. Un index inutile alourdit les écritures et ne doit pas être appliqué à l’aveugle.
Buffer pool InnoDB
Le buffer pool doit laisser de la mémoire à PHP, au système et aux autres services. Il n’existe pas de pourcentage valable pour tous les serveurs: sur une base dédiée, l’enveloppe peut être plus importante que sur un serveur partagé avec PHP-FPM.
[mysqld]
innodb_buffer_pool_size = 2G
slow_query_log = 1
long_query_time = 1Ces valeurs illustrent le type de réglages à tester; adaptez-les à la RAM, à la taille réelle de la base et aux données mesurées. Documentez toujours la configuration précédente avant un redémarrage.
Méthode de test après chaque changement
- Effectuez une sauvegarde et notez le réglage initial.
- Modifiez un seul paramètre.
- Videz le cache nécessaire sans masquer les problèmes.
- Testez les parcours critiques: accueil, catégorie, produit, recherche, connexion et commande.
- Comparez les logs, consommation et temps de réponse.
- Gardez le changement seulement s’il améliore une mesure définie sans dégrader la stabilité.
Erreurs fréquentes
Augmenter toutes les limites en même temps
Vous ne saurez pas ce qui a aidé ou aggravé le problème. Pire, une hausse simultanée des workers et de memory_limit peut provoquer une saturation brutale de RAM.
Confondre cache et correction de fond
Le cache peut réduire la charge, mais une requête SQL lente, un module défaillant ou un import lancé en journée doit être corrigé à sa source.
Appliquer une configuration trouvée sur Internet
Une configuration publiée pour un serveur de 32 Go de RAM n’est pas adaptée à un VPS de 4 Go. Les exemples doivent toujours être relus à la lumière de votre architecture.
Checklist de mise en production
- Sauvegarde vérifiée avant modification.
- Compatibilité PHP contrôlée pour PrestaShop et les modules critiques.
- Mesures avant/après enregistrées.
- Requêtes lentes identifiées avant modification de la base.
- Retour arrière documenté.
- Parcours de commande testé après redémarrage.
Pour aller plus loin
- Activer le mode debug PrestaShop sans exposer sa boutique
- Comprendre le cache Valkey dans PrestaShop
- Choisir un hébergement adapté à PrestaShop
