Serveur dédié PrestaShop : installation et optimisation Debian pour gros catalogue

Table des matières :

1. Dimensionnement d’un serveur dédié PrestaShop pour gros catalogue (et quand séparer les rôles)
2. Debian 12 (Bookworm) : installation minimale, I/O et durcissement système
3. Stack web sur Debian : Nginx + PHP-FPM, OPcache, et sizing des workers
4. MariaDB/MySQL : InnoDB, buffers, index et discipline de maintenance
5. Cache, recherche, supervision : tenir la charge et arrêter de piloter à l’aveugle

Sur un gros catalogue PrestaShop (ordre de grandeur : >100k produits, >500k déclinaisons, >5M lignes sur ps_stock_available, ps_product_attribute, ps_specific_price…), le serveur dédié n’est pas “juste” un hébergement plus puissant : c’est la condition minimale pour reprendre le contrôle sur l’I/O disque, la RAM (cache MySQL + OPcache) et la latence réseau. Le cœur PrestaShop reste très SQL‑bound (beaucoup de requêtes par page, notamment en listing et panier), et une boutique qui “tient” en staging peut s’écrouler en prod dès que l’on ajoute du trafic + un import + un crawl SEO.

Un scénario typique sur gros catalogue : un import met à jour prix/stock (écritures + invalidations), le back‑office déclenche des recalculs (indexation, règles paniers), pendant que Googlebot repasse sur des facettes et que des clients naviguent. Le symptôme n’est pas “un CPU à 100%” : c’est souvent une latence disque qui grimpe, des threads MySQL en attente, puis des timeouts PHP qui font exploser le taux d’erreurs (502/504) au pire moment.

Dimensionnement d’un serveur dédié PrestaShop pour gros catalogue (et quand séparer les rôles)

La ressource limitante sur gros catalogue est rarement le CPU en premier : c’est le couple latence disque / cache RAM côté base de données. Sur un dédié “mono‑machine” (web + DB), l’objectif est simple : garder un maximum de working set InnoDB en mémoire et éviter les flushs agressifs. En pratique, en‑dessous de 64 Go RAM on arrive vite à arbitrer entre innodb_buffer_pool_size, OPcache, page cache Linux et Redis. Pour des catalogues massifs + BO utilisé (imports, back‑office), 128 Go est un confort réel.

Sur le CPU, privilégiez fréquence + IPC plutôt que “plein de cœurs lents”. PrestaShop exécute beaucoup de PHP par requête, et PHP‑FPM profite d’un nombre raisonnable de workers (souvent 2–4× le nombre de cœurs selon la charge). Un 8–16 vCPU moderne + NVMe est une base saine. Sur le stockage, la différence entre SSD SATA et NVMe se voit immédiatement sur MySQL (fsync, redo logs, random reads). Si vous pouvez, partez sur RAID1 NVMe (matériel ou mdadm) : vous gagnez en résilience sans pénaliser l’I/O en lecture.

Pour cadrer rapidement, voici une grille “ops” (à valider par mesures : taille DB, ratio trafic, modules, fréquence des imports) :

Profil boutique (ordre de grandeur)	Web + DB sur 1 machine	Reco split Web / DB	Notes clés
~100k produits / ~500k déclinaisons	8–12 vCPU, 64–96 Go RAM, NVMe	Pas obligatoire	Priorité : buffer pool + OPcache, index propres
>200k produits + imports fréquents	12–16 vCPU, 128 Go RAM, RAID1 NVMe	Souvent oui	Import = écritures + locks : isolez la DB
Catalogue massif + fort SEO/crawl	16 vCPU, 128–256 Go RAM	Oui	Le crawl fait ressortir les requêtes non indexées

Quand faut‑il séparer web et DB ? Dès que vous constatez l’un des symptômes suivants : (1) iowait récurrent pendant les pics (import/crawl), (2) Threads_running MySQL qui explose et latences p95 qui dérapent, (3) contention mémoire (swap ou OOM). Sur un gros catalogue, le split “web” + “DB” n’est pas du luxe, c’est une manière d’isoler les bruits de voisinage internes.

• Réseau : si vous splittez web et DB, privilégiez un lien privé (VLAN/VRF du provider) et une MTU cohérente. La latence inter‑machines devient un paramètre de perf (requêtes SQL nombreuses). Dans un contexte France/UE, choisir un datacenter proche de votre base d’utilisateurs (et garder DB + web dans la même zone) réduit les RTT inutiles.
• Sauvegardes : la séparation des rôles aide aussi à maîtriser l’impact des backups (snapshots, dumps) : un mysqldump mal planifié sur une machine mono‑rôle peut dégrader le front.

Sur ce point, gardez en tête la règle de diagnostic de Brendan Gregg : « for every resource, check utilization, saturation, and errors » (USE method) — c’est exactement la grille à appliquer avant de “rajouter du CPU”. Source : Brendan Gregg, The USE Method The USE Method.

Debian 12 (Bookworm) : installation minimale, I/O et durcissement système

Le contexte de cet article : Debian 12, PrestaShop 9.x, PHP 8.2 (recommandation prudente) ou PHP 8.3 si votre stack modules est validée. Vérifiez votre matrice PHP côté boutique (modules, overrides, libs) : les incohérences de docs côté écosystème sont fréquentes, et le coût d’un rollback PHP en prod est rarement acceptable. Référence interne utile : PrestaShop 9 : versions PHP recommandées et incohérences de documentation.

Côté installation OS : partez sur une image minimaliste (pas de desktop, pas de packages “confort”), activez SSH par clés, et fixez tout de suite les garde‑fous système. À minima : nftables, fail2ban (ou équivalent), unattended-upgrades, et des limites de fichiers ouvertes (sinon Nginx/PHP‑FPM/MySQL se marcheront dessus). Exemple :

apt update && apt -y full-upgrade
apt -y install nftables fail2ban unattended-upgrades ca-certificates curl gnupg lsb-release

# Limites (exemple)
cat >/etc/security/limits.d/99-custom.conf <<'EOF'
www-data  soft nofile  65535
www-data  hard nofile  65535
mysql     soft nofile  65535
mysql     hard nofile  65535
EOF

Pour l’I/O, ne vous racontez pas d’histoires : un gros catalogue va marteler le disque (index, tmp tables, logs, sessions, images). Utilisez un FS standard (ext4 fonctionne très bien), montez avec noatime, surveillez l’espace libre et évitez les partitions minuscules.

Quelques points concrets à décider dès l’installation (et à documenter, pour éviter les “tweaks” de dernière minute en incident) :

• Schéma de partitions : séparer au minimum /var/lib/mysql (DB) et /var/log si vous avez des volumes distincts. En cas de saturation logs, vous évitez d’écraser la DB.
• TRIM sur SSD/NVMe : vérifiez que fstrim.timer est actif sur Debian 12 (souvent activé par défaut). Sur la durée, ça aide à garder des perfs d’écriture plus stables.
• Temps système : NTP actif (chrony ou systemd-timesyncd) — important pour corréler logs Nginx/PHP/MySQL lors d’une analyse de lenteur.

Ajustez aussi des sysctl basiques (sans tomber dans le tuning “cargo cult”) :

cat >/etc/sysctl.d/99-prestashop.conf <<'EOF'
vm.swappiness=10
vm.vfs_cache_pressure=50
net.core.somaxconn=4096
fs.file-max=2097152
EOF
sysctl --system

Le point critique : ne forcez pas Debian à swaper “par design”. Sur une boutique, swap = latence = timeout applicatif = panier perdu. Si vous n’avez pas assez de RAM, ajoutez de la RAM ou séparez les rôles.

Enfin, côté durcissement SSH (souvent oublié sur des dédiés “montés vite”), au minimum : clés uniquement, pas de root direct, et un AllowUsers explicite. Exemple de contrôle simple après modification :

sshd -t && systemctl reload ssh

Stack web sur Debian : Nginx + PHP-FPM, OPcache, et sizing des workers

Sur Debian 12, le couple Nginx + PHP‑FPM est généralement plus prévisible qu’Apache mod_php pour encaisser des pics. Nginx gère mieux les connexions concurrentes, et PHP‑FPM vous permet de régler précisément la consommation mémoire par pool. Le défaut classique sur PrestaShop : pousser pm.max_children trop haut sans mesurer la RAM réelle par process (catalogues lourds + modules = 150–300 Mo par worker dans des cas réalistes). Résultat : OOM et “random 502”.

Commencez par un vhost Nginx propre (HTTP/2, compression, headers), puis dimensionnez PHP‑FPM à partir de mesures. Exemple de pool (à ajuster) :

; /etc/php/8.2/fpm/pool.d/prestashop.conf
[prestashop]
user = www-data
group = www-data
listen = /run/php/php8.2-fpm-prestashop.sock
listen.owner = www-data
listen.group = www-data
pm = dynamic
pm.max_children = 40
pm.start_servers = 8
pm.min_spare_servers = 8
pm.max_spare_servers = 16
pm.max_requests = 500
request_terminate_timeout = 120s
php_admin_value[memory_limit] = 512M

La méthode fiable pour “sizer” pm.max_children n’est pas une valeur magique : c’est un calcul avec garde‑fou.

1) Mesurez la conso d’un worker en charge (front + BO, pages lourdes, panier). Par exemple :

ps -o rss,cmd -C php-fpm8.2 --sort=-rss | head

2) Définissez une enveloppe RAM dédiée à PHP (ex. : sur un mono‑rôle 128 Go, vous pouvez décider “max 20–30 Go pour PHP” selon la taille du buffer pool, Redis, OS).

3) Appliquez une règle simple :

• pm.max_children ≈ RAM_allouée_à_PHP / RSS_moyen_worker

Exemple : 24 Go / 240 Mo ≈ 100 workers (mais vous gardez une marge, et vous vérifiez côté DB si ça augmente la contention). Sur gros catalogue, “plus de workers” peut aussi augmenter la latence si MySQL devient le goulot : d’où l’intérêt d’observer ensemble Nginx/PHP/MySQL.

OPcache est non‑négociable sur PrestaShop (autoloader, Symfony, hooks). Le manuel PHP est explicite : « OPcache improves PHP performance by storing precompiled script bytecode in shared memory » (PHP Manual, OPcache) PHP Manual, OPcache. En gros catalogue, ne sous‑dimensionnez pas opcache.memory_consumption ni opcache.max_accelerated_files, sinon vous recréez du CPU (compilation) et vous dégradez le TTFB. Pour des codebases + modules volumineux, 256–512 Mo d’OPcache est fréquent.

• éviter les surprises liées à l’horloge/mtime des fichiers (opcache.validate_timestamps=0) uniquement si vous avez un déploiement contrôlé (et un reload PHP‑FPM à chaque release) ;
• limiter les effets de bord mémoire via pm.max_requests (recyclage des workers).

Pour aller plus loin sur les réglages utiles (et éviter les paramètres magiques), référez‑vous à : PHP OPcache : paramètres recommandés pour optimiser les performances. Et côté PrestaShop, ne mélangez pas environnement dev/prod : CCC, cache Smarty, et désactivation du debug doivent être traités comme des prérequis, sinon vous “benchmarkez” une boutique qui n’existera jamais en production. Référence : PrestaShop : optimiser performance via cache Smarty, CCC et CDN.

MariaDB/MySQL : InnoDB, buffers, index et discipline de maintenance

Sur gros catalogue, MySQL/MariaDB est le composant qui décide si votre dédiée “tient”. Le réglage central est innodb_buffer_pool_size (mémoire dédiée au cache des pages de données et index InnoDB). Si vous êtes sur un serveur mono‑rôle, une approche courante est 60–70% de la RAM (en laissant de l’air à PHP‑FPM + OS + Redis). Si vous avez séparé la DB, montez plutôt à 75–85%. L’objectif est de maximiser le ratio de lectures servies depuis la mémoire, pas de faire joli dans un fichier de conf.

Exemple de base (à adapter à votre RAM, vos disques, votre version MariaDB/MySQL) :

# /etc/mysql/mariadb.conf.d/60-prestashop.cnf
[mysqld]
innodb_buffer_pool_size = 64G
innodb_buffer_pool_instances = 8
innodb_log_file_size = 2G
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit = 1
max_connections = 300
thread_cache_size = 100
tmp_table_size = 256M
max_heap_table_size = 256M
slow_query_log = 1
long_query_time = 0.2
log_output = FILE

Ne copiez pas ces valeurs en aveugle : le point important est la méthode. Activez le slow query log, corrélez avec les pages lentes, et corrigez les index (ou les requêtes) au lieu de “sur‑allouer”.

• 1/ Isoler le top 10 des requêtes lentes (par temps total, pas uniquement par “max”). Le slow log est la base ; ensuite, un outil d’agrégation (type digest) vous aide à prioriser.
• 2/ Vérifier EXPLAIN : cherchez les type=ALL, Using temporary, Using filesort, et surtout les requêtes qui filtrent sur des colonnes non indexées dans des tables volumineuses (ps_specific_price, ps_product_attribute, ps_stock_available).
• 3/ Proposer un index composite aligné sur le WHERE + JOIN réels. Sur PrestaShop multi-boutique, l’oubli de id_shop dans un index est un classique.
• 4/ Re-tester en charge (trafic simulé + import + crawl si possible) : certaines optimisations déplacent la charge ailleurs (CPU, mémoire, locks).

Pour la méthode d’analyse et les pièges classiques (joins inutiles, filesort, temporary), appuyez‑vous sur : PrestaShop MySQL : analyser slow query log et optimiser index et, côté schéma/collation, sur : Prérequis système : migration MySQL vers MariaDB, InnoDB et collation UTF-8.

Deux anti‑patterns à éviter sur PrestaShop : (1) laisser des modules injecter des requêtes non indexées sur les listings (ça se voit en prod quand Googlebot passe), (2) sous‑estimer la maintenance “catalogue” (imports massifs, ps_specific_price, tables de recherche).

• Surveiller la croissance des tables connues pour exploser (prix spécifiques, déclinaisons, logs applicatifs) et poser des seuils d’alerte (taille disque + temps de requêtes).
• Planifier les traitements lourds hors pic (rebuild d’index de recherche, imports) et limiter les parallélismes côté import si la DB sature.
• Éviter les migrations “à chaud” : ajouter un index sur une table à plusieurs millions de lignes en plein pic, sans fenêtre et sans plan de rollback, est une source fréquente d’incident.

Le cœur n’est pas conçu pour absorber des écritures lourdes en continu sans stratégie : si vous avez des imports fréquents, pensez à décorréler via files/queues et traitements asynchrones (cf. Symfony Messenger : configuration avancée, choix du transport et performances).

Cache, recherche, supervision : tenir la charge et arrêter de piloter à l’aveugle

Sur gros catalogue, Redis n’est pas un gadget : c’est un moyen de déplacer des accès “répétitifs” hors MySQL (sessions, cache applicatif, certains modules). Dans un setup PrestaShop, Redis améliore souvent la stabilité du checkout et du BO sous charge, mais seulement si vous avez déjà une DB saine : Redis ne compensera pas des requêtes mal indexées.

Une manière saine d’introduire Redis (et d’éviter “on l’a mis, ça n’a rien changé”) :

• commencer par sessions (effet stabilité) ;
• mesurer le gain et surveiller la mémoire Redis + évictions ;
• étendre au cache applicatif uniquement si vos modules/stack sont compatibles (et si vous savez invalider proprement).

La recherche interne est un autre point de rupture : l’index MySQL natif de PrestaShop est vite insuffisant (pertinence, tolérance fautes, volumétrie). Sur gros catalogue, basculer vers un moteur dédié (Meilisearch / Elasticsearch) n’est pas “SEO only”, c’est une décision de perf et d’UX. Selon vos contraintes (RAM, ops, pertinence), lisez : Moteur de recherche marketplace : Meilisearch, Elasticsearch ou Algolia et, pour comprendre ce que fait réellement l’index interne, Index de recherche PrestaShop : fonctionnement, tables SQL et pondérations. Si vous voulez du live search + tolérance fautes + tri commercial, la contrainte principale devient l’architecture (indexation incrémentale, backpressure, cohérence) plus que le “module”. Référence : Recherche interne PrestaShop : live search, tolérance fautes et tri commercial.

La supervision : sans métriques, vous jouez au hasard. Installez au minimum nodeexporter + mysqldexporter et exposez des métriques PHP‑FPM/Nginx. Côté stack, Prometheus est un standard de fait ; partez d’alertes simples (CPU steal, iowait, saturation DB, erreurs 5xx, taille des pools) et itérez.

Un socle d’indicateurs “actionnables” (pas juste jolis) sur PrestaShop gros catalogue :

• Nginx : taux de 5xx, latence p95, upstream time (PHP) vs request time (réseau/client).
• PHP‑FPM : max children reached, durée moyenne des requêtes, workers “slow” (et corrélation avec des endpoints : panier, recherche, listing).
• MySQL/MariaDB : Threads_running, ratio hits buffer pool, temps de locks, nombre de temporary tables sur disque (si ça grimpe, c’est souvent un problème de requêtes + taille tmp).
• Système : iowait, saturation NVMe, espace disque (DB + images + logs), erreurs kernel.

Guide interne : Prometheus : configuration des alertes, métriques et requêtes PromQL. Et si vous montez vers une archi HA (deux web derrière LB), HAProxy reste une brique robuste à condition de maîtriser health checks et sticky sessions : HAProxy : configuration avancée ACL, health checks et sticky sessions.

Enfin, la réalité “run” : sauvegardes testées (restores), rotation de logs, contrôle de l’espace disque (images + logs MySQL), et durcissement applicatif. Un point souvent sous-estimé en e‑commerce : une sauvegarde “qui tourne” n’est pas une sauvegarde “restorable”. Planifiez périodiquement un test de restauration (sur une VM de préprod) et documentez un RTO/RPO réaliste.

PrestaShop a un historique d’attaques côté modules / BO ; traiter la sécurité comme une checklist ponctuelle est une erreur. Pour cadrer une démarche d’audit et de durcissement : Audit sécurité PrestaShop : méthodologie, livrables et durcissement et, côté perf globale (catalogue + CWV), gardez une vue bout‑en‑bout : PrestaShop performance : optimiser gros catalogues et Core Web Vitals.

Si vous cherchez un cadrage “serveur dédié e‑commerce” plus large (NVMe, Redis, Varnish, HA), voir aussi : Serveurs dédiés infogérés e-commerce : NVMe, Redis, Varnish et haute disponibilité.