Optimisation d’un serveur dédié pour les sites à fort trafic

L’optimisation d’un serveur dédié pour les sites à fort trafic consiste à régler ensemble le processeur, la RAM, le stockage, le réseau, le serveur web, la base de données, le cache, la sécurité et la supervision afin que le site reste rapide, stable et sécurisé lors des pics de visiteurs. En pratique, l’objectif est de réduire le temps de réponse des pages, de traiter davantage de requêtes par seconde sans erreur, de limiter le gaspillage de ressources et de détecter les incidents avant qu’ils ne deviennent visibles pour les utilisateurs. Pour un site e-commerce, un média en ligne, une application SaaS, une plateforme de jeu, un forum ou une page de campagne marketing, un serveur dédié bien configuré offre généralement des performances plus constantes, un meilleur contrôle technique et des coûts plus prévisibles qu’une infrastructure mutualisée.

Dans ce guide, nous allons aborder l’optimisation d’un serveur dédié non pas sous forme de conseils génériques, mais avec des points de contrôle applicables sur des systèmes réels. Préparé pour le blog Hostragons, ce contenu couvre le choix du serveur, les réglages Linux, l’optimisation NGINX ou Apache, PHP-FPM, la configuration MySQL ou MariaDB, le cache Redis, le CDN, la sécurité, la sauvegarde et la supervision. Si vous mettez en place une nouvelle infrastructure, il est utile d’évaluer les options Serveur Loué ; si vous migrez depuis une configuration plus modeste, consultez aussi les guides Serveur VPS ; et pour sécuriser les connexions, pensez à la page certificats SSL.

Que signifie vraiment « fort trafic » pour un serveur dédié ?

Un site à fort trafic ne se définit pas uniquement par un grand nombre de visiteurs par jour. Les critères les plus importants sont le nombre d’utilisateurs simultanés, le volume de requêtes par seconde, la charge des traitements dynamiques, le poids des téléchargements, le coût des requêtes en base de données et les pics soudains pendant les campagnes ou les événements spéciaux. Par exemple, un blog principalement statique qui reçoit 200 000 visites par jour peut consommer relativement peu de ressources avec un bon cache. À l’inverse, une boutique en ligne avec 30 000 visites quotidiennes peut être beaucoup plus lourde à exécuter à cause du panier, du paiement, des stocks, des comptes clients et des recherches produits.

Lors de l’évaluation initiale, il faut mesurer les indicateurs suivants :

• Utilisateurs simultanés : le nombre de sessions actives au même moment. Sur un site de campagne, cette valeur peut être multipliée par 5 ou 10 en quelques minutes.
• RPS : le nombre de requêtes HTTP par seconde. La page d’accueil, les pages produits, les API et les fichiers statiques doivent être suivis séparément.
• TTFB : le temps jusqu’au premier octet reçu. Moins de 200 ms est excellent, 200 à 500 ms reste acceptable, au-delà de 1 seconde il faut investiguer.
• Charge CPU : elle doit être interprétée selon le nombre de cœurs. Sur un serveur 8 cœurs, une charge moyenne constante de 8 indique une limite ; 12 ou plus peut justifier une alerte.
• Utilisation de la RAM : avoir peu de mémoire libre n’est pas forcément mauvais, car Linux utilise la RAM pour le cache. Le vrai signal d’alerte est l’usage régulier du swap.
• IOPS et latence disque : les disques NVMe font souvent une différence nette pour les bases de données et les sites générant beaucoup de logs.
• Taux d’erreur : les réponses 5xx, les timeouts et les erreurs de connexion à la base apparaissent surtout lorsque le trafic augmente.

Bien choisir son serveur dédié : l’optimisation commence par le matériel

Même avec les meilleurs réglages logiciels, un mauvais choix matériel crée rapidement un goulet d’étranglement. Pour choisir un serveur dédié destiné à un site très fréquenté, il ne suffit pas de regarder le nombre de cœurs CPU. Il faut comprendre la nature de la charge : est-elle surtout liée au processeur, à la mémoire, aux entrées/sorties disque ou à la bande passante réseau ?

CPU : nombre de cœurs ou fréquence ?

Les performances CPU sont essentielles pour PHP, Node.js, Python et les bases de données. Si le trafic est fortement concurrentiel et composé de nombreuses requêtes parallèles, le nombre de cœurs apporte un vrai avantage. Mais pour que chaque requête individuelle se termine vite, une fréquence élevée reste également déterminante. Par exemple, pour des systèmes dynamiques basés sur PHP comme WordPress WooCommerce, 8 à 16 cœurs à fréquence élevée donnent souvent un bon équilibre. En revanche, si vous effectuez de la conversion vidéo, du reporting lourd ou de nombreuses tâches cron intensives, augmenter le nombre de cœurs devient plus pertinent.

RAM : le meilleur terrain d’investissement pour le cache

Sur un site à fort trafic, la RAM ne sert pas seulement à faire fonctionner l’application. Elle est utilisée par les buffers de base de données, Redis, les processus PHP-FPM et le cache disque du système d’exploitation. 16 Go de RAM peuvent être considérés comme un point d’entrée ; pour un e-commerce actif, un portail d’actualité ou une grande plateforme avec espace membre, 32 Go, 64 Go ou davantage offrent une marge plus confortable. Si l’usage du swap apparaît en continu, il faut d’abord vérifier les fuites mémoire et le nombre de workers, puis envisager une montée en RAM.

Stockage : pourquoi le NVMe compte autant ?

Les SSD ont longtemps été la référence, mais pour les sites à base de données fortement sollicitée, les disques NVMe apportent une latence plus faible et davantage d’IOPS. Dans les scénarios MySQL InnoDB, Elasticsearch, traitement de logs ou écritures fréquentes, la latence disque se répercute directement sur la vitesse d’affichage des pages. Si la base de données tourne sur le même serveur, choisir du NVMe peut parfois apporter un bénéfice plus visible qu’un simple upgrade CPU.

Réseau : bande passante et volume de trafic

Pour les sites qui servent beaucoup d’images, de vidéos, de fichiers logiciels ou de médias lourds, la capacité réseau devient critique. Un port 1 Gbps suffit à la plupart des sites web, mais le besoin réel doit être calculé selon le trafic mensuel et l’utilisation pendant les heures de pointe. L’usage d’un CDN réduit alors la charge du serveur d’origine. Pour centraliser la gestion du nom de domaine et du DNS, les contenus Requête de domaine et Gestion DNS peuvent aussi entrer dans la planification.

Une approche par couches pour optimiser un serveur dédié

Il n’existe pas de bouton magique. Une optimisation efficace d’un serveur dédié se fait par couches : système d’exploitation, serveur web, runtime applicatif, base de données, cache, distribution des fichiers, sécurité et supervision doivent être traités ensemble. Le tableau ci-dessous résume les goulets d’étranglement les plus fréquents et les actions prioritaires.

Réglages du système d’exploitation et du noyau

Sur les serveurs dédiés Linux, Ubuntu LTS, Debian, AlmaLinux ou Rocky Linux sont souvent privilégiés. Le plus important est d’utiliser une distribution à jour, maintenue et maîtrisée par votre équipe. Après l’installation initiale, il faut désactiver les services inutiles, planifier les mises à jour de sécurité et vérifier les limites système de base.

Limites de descripteurs de fichiers

En période de fort trafic, chaque connexion, fichier, socket ou opération de log peut se heurter aux limites système. Si NGINX ou PHP-FPM doit gérer beaucoup de connexions simultanées, la limite de fichiers ouverts doit être augmentée. Des valeurs par défaut comme 1024 deviennent vite insuffisantes ; 65535 ou davantage peut être envisagé selon la capacité du serveur. Mais relever la limite ne suffit pas : elle doit rester cohérente avec les réglages de workers et de connexions.

TCP et files d’attente de connexions

Lors d’une grosse campagne, si la file d’attente de connexions se remplit, les utilisateurs peuvent recevoir une erreur avant même d’atteindre le site. Des paramètres comme somaxconn, tcp_max_syn_backlog et la plage de ports doivent être ajustés selon les mesures. Il vaut mieux éviter les fichiers sysctl copiés au hasard depuis Internet et préférer des réglages validés par test de charge. Exemple simple : pour un site média visant 10 000 connexions simultanées, la capacité des workers du serveur web, le backlog du noyau et les connexions vers les upstreams doivent être planifiés ensemble.

Optimisation du serveur web : NGINX, Apache et LiteSpeed

Le serveur web est la première couche qui reçoit les requêtes des utilisateurs. NGINX se distingue par son architecture événementielle, très efficace avec de nombreuses connexions simultanées. Apache reste courant grâce à sa flexibilité et à la prise en charge des fichiers .htaccess. LiteSpeed peut produire d’excellents résultats, notamment sur WordPress avec LSCache. Quel que soit le logiciel choisi, l’objectif reste le même : servir les fichiers statiques rapidement, transmettre les requêtes dynamiques au bon upstream et bloquer les requêtes inutiles le plus tôt possible.

Réglages critiques pour NGINX

• worker_processes : l’option auto convient souvent, car elle s’adapte au nombre de cœurs CPU.
• worker_connections : la valeur doit correspondre au volume de connexions simultanées attendu et aux limites de fichiers ouverts.
• keepalive_timeout : une valeur trop longue consomme des connexions ; trop courte, elle augmente le coût des reconnexions. Une plage de 10 à 30 secondes est équilibrée dans beaucoup de cas.
• gzip ou Brotli : ces compressions réduisent la bande passante pour HTML, CSS, JS et JSON.
• En-têtes de cache statique : les images, polices et fichiers JS doivent recevoir des directives de cache longue durée.
• Rate limiting : il limite les bots et les scans malveillants.

Si vous utilisez Apache

Avec Apache, le choix du MPM est très important. Utiliser event MPM avec PHP-FPM peut être plus efficace que l’ancienne approche prefork. Les fichiers .htaccess étant lus à chaque requête, ils ont un coût de performance ; lorsque c’est possible, il vaut mieux déplacer les règles dans la configuration principale. Le nombre de modules doit être réduit et les modules inutilisés désactivés.

Optimisation de PHP-FPM et de la couche applicative

Pour WordPress, Laravel, OpenCart, Magento ou une application PHP sur mesure, les réglages PHP-FPM ont un impact direct sur les performances. L’erreur la plus fréquente consiste à augmenter pm.max_children sans calculer la RAM disponible. Si chaque worker PHP consomme en moyenne 80 Mo et que 8 Go peuvent être alloués à PHP, la limite théorique est d’environ 100 workers. Mais il faut aussi réserver de la mémoire pour la base de données, Redis et le système d’exploitation. Une valeur réaliste doit être plus prudente, puis vérifiée sous charge.

Utilisation d’OPcache

OPcache conserve en mémoire la version compilée des fichiers PHP et réduit donc la consommation CPU. En production, opcache.enable doit être actif, opcache.memory_consumption doit être adapté à la taille du projet et le processus de déploiement doit inclure un mécanisme de purge du cache. Sur de gros projets WordPress ou Laravel, laisser OPcache désactivé augmente inutilement la charge processeur.

Cron et tâches en arrière-plan

Dans les systèmes à fort trafic, les rapports, l’envoi d’e-mails, la synchronisation de stock et les imports de données ne devraient pas être exécutés pendant la requête utilisateur. Il faut utiliser une file de tâches ; Redis, RabbitMQ ou une solution similaire permet de séparer les workers d’arrière-plan. Les parcours critiques, comme la page de paiement, répondent alors plus vite.

Optimisation de la base de données : MySQL et MariaDB

Sur beaucoup de sites très fréquentés, le principal point de blocage est la base de données. Si l’usage CPU du serveur paraît faible alors que les pages sont lentes, le problème peut venir de requêtes lentes ou de verrous. La première étape consiste à activer le slow query log et à identifier les requêtes les plus coûteuses. Ajouter un index adapté peut être moins cher et plus efficace qu’une mise à niveau matérielle.

InnoDB Buffer Pool

Sur un serveur fortement orienté MySQL ou MariaDB, l’InnoDB buffer pool permet de conserver les données en RAM. Sur un serveur dédié uniquement à la base de données, 60 à 70 % de la mémoire peuvent être réservés au buffer pool. Si le web et la base tournent sur le même serveur dédié, ce ratio doit être choisi avec plus de prudence. Sur une machine de 32 Go de RAM, un buffer pool de 12 à 18 Go peut constituer un bon point de départ selon les besoins de l’application et du cache.

Analyse des index et des requêtes

La sortie EXPLAIN indique si une requête parcourt toute une table ou utilise correctement les index. Les listes de produits, filtres de catégories, recherches, tables membres et commandes doivent être audités régulièrement. Dans une table de commandes d’un million de lignes, un mauvais index peut forcer le balayage de centaines de milliers de lignes à chaque requête. Lorsque le trafic augmente, cette situation fait grimper rapidement le CPU et les I/O disque.

Quand faut-il séparer la base de données ?

Un seul serveur dédié peut suffire longtemps. Toutefois, si le CPU, la RAM et les I/O disque sont sollicités simultanément, déplacer la base de données vers un serveur séparé devient pertinent. Si le trafic de lecture est très élevé, une read replica peut être utile. Pour les systèmes avec beaucoup d’écritures, l’architecture applicative et la conception des tables doivent aussi être revues.

Stratégie de cache : le gain de performance le plus rentable

Le cache est l’un des leviers qui offre le meilleur retour sur investissement pour les sites à fort trafic. Le but est simple : éviter de régénérer le même contenu à chaque requête. La stratégie doit être multicouche : cache navigateur, cache CDN, cache de page, cache objet et mécanismes applicatifs proches du query cache doivent être pensés ensemble.

Cache de page

Pour les blogs, sites d’actualité et pages institutionnelles, le cache de page complet réduit massivement la charge serveur. Par exemple, une page WordPress sans cache lance PHP et MySQL à chaque requête ; avec le cache activé, NGINX peut renvoyer un fichier HTML statique. Sur le même matériel, la capacité en requêtes par seconde peut alors être multipliée plusieurs fois.

Redis ou Memcached

Redis est souvent utilisé pour les sessions, le cache objet, les données transitoires et les files de tâches. Sur des systèmes dynamiques comme WooCommerce, les produits, les pages hors panier, les paramètres et les requêtes fréquemment lues peuvent être accélérés avec Redis. Il faut définir une limite mémoire et choisir la politique d’éviction en connaissance de cause ; sinon, lorsque la mémoire est pleine, des suppressions de cache inattendues peuvent se produire.

CDN et ressources statiques

Un CDN permet de servir les images, CSS, JS, polices et certains contenus HTML cacheables depuis un point plus proche de l’utilisateur. La bande passante et le nombre de requêtes vers le serveur dédié d’origine diminuent. Pour les sites qui reçoivent des visiteurs depuis plusieurs pays, le CDN réduit aussi la latence. Pour une configuration HTTPS sécurisée, il est judicieux de le planifier avec certificats SSL ; pour la gestion du nom de domaine, pensez aussi à Transfert de domaine.

Optimisation des images, des fichiers et du front-end

L’optimisation serveur ne se limite pas au backend. De grandes images, des fichiers JavaScript inutiles et de mauvais en-têtes de cache peuvent faire paraître lent même un serveur dédié puissant. Les formats WebP ou AVIF, le lazy loading, les images responsives et la réduction des scripts tiers inutiles ont un impact direct sur les performances.

Voici un exemple concret : sur la page d’accueil d’un site e-commerce avec 6 Mo d’images, convertir les visuels en WebP et les servir aux bonnes dimensions peut faire descendre le poids total de la page à environ 1,8 Mo. Pour les utilisateurs mobiles, cela peut accélérer l’affichage de plusieurs secondes et réduire nettement la quantité de données transférées depuis le serveur.

Optimisation de la sécurité : la partie cachée de la performance

Les bots, les tentatives de brute force, les scans malveillants et les trafics proches du DDoS consomment des ressources serveur. La sécurité est donc une composante directe de l’optimisation des performances. Si votre site semble lent pour les vrais utilisateurs, la cause n’est pas toujours une mauvaise requête SQL : il peut simplement être saturé par du trafic bot inutile.

Checklist de sécurité de base

• La connexion SSH root doit être désactivée et l’accès par clé doit être privilégié.
• Changer le port SSH ne suffit pas ; il faut compléter avec fail2ban et des restrictions IP.
• Un WAF ou pare-feu applicatif doit être activé.
• Les panneaux d’administration doivent être protégés par rate limit et, si possible, restriction IP.
• Les mises à jour doivent être appliquées régulièrement et les paquets inutilisés supprimés.
• HTTPS doit être imposé avec Let’s Encrypt ou des certificats SSL commerciaux.
• Les sauvegardes doivent être chiffrées, stockées dans un emplacement séparé et testées en restauration.

Lors de la planification de la couche sécurité, intégrer des liens internes vers des sujets comme Hébergement web Güvenliği, certificats SSL et Sécurité des E-mails d'Entreprise renforce aussi le parcours utilisateur.

Supervision, logs et alertes : on n’optimise pas ce que l’on ne mesure pas

Sur un serveur dédié à fort trafic, la supervision n’est pas un luxe, c’est une obligation. Il faut suivre le CPU, la RAM, le disque, le réseau, l’état des services, les codes de réponse HTTP, la longueur des files, le temps des requêtes SQL et l’expiration des certificats SSL. Des outils comme Prometheus, Grafana, Netdata, Zabbix ou équivalents peuvent être utilisés. Même dans une installation simple, le suivi d’uptime et les alertes par e-mail ou messagerie sont indispensables.

Seuils d’alerte à surveiller

• Déclenchez une alerte si la charge CPU dépasse 80 % du nombre de cœurs pendant 10 minutes.
• Lancez une analyse si le swap dépasse durablement 512 Mo après une forte utilisation de la RAM.
• Alertez dès que le disque dépasse 80 % d’occupation ; 90 % doit être considéré comme une urgence.
• Si le taux d’erreurs 5xx dépasse 1 %, vérifiez les logs applicatifs et upstream.
• Si le TTFB moyen dépasse 500 ms, examinez le cache, la base de données et PHP-FPM.
• Créez une alerte 14 jours avant l’expiration du certificat SSL.

Les logs doivent eux aussi être maîtrisés. Les access logs, error logs, logs de base de données et logs applicatifs peuvent remplir le disque s’ils grossissent sans contrôle. Des politiques logrotate doivent être définies, et les logs critiques peuvent être envoyés vers un système centralisé.

Tests de charge et planification de capacité

Pour valider une optimisation, il faut effectuer des tests de charge réalistes. ApacheBench peut suffire pour des tests très simples, mais des outils comme k6, JMeter ou Locust permettent de simuler des parcours utilisateurs plus proches de la réalité. Tester uniquement la page d’accueil est trompeur. La recherche produit, les filtres de catégories, la connexion membre, l’ajout au panier, les étapes avant paiement et les appels API doivent être mesurés séparément.

Lors des tests, utilisez un volume de données proche de la production. Une base de test avec 100 produits ne se comporte pas comme une base réelle avec 500 000 produits. Pendant le test, l’état du cache CDN, la protection bot et les index de base de données doivent aussi être proches de l’environnement final. Les objectifs doivent être définis à l’avance : par exemple, avec 2 000 utilisateurs simultanés, le 95e percentile du temps de réponse doit rester sous 800 ms et le taux d’erreur sous 0,5 %.

Checklist étape par étape pour optimiser un serveur dédié

L’ordre ci-dessous propose une méthode applicable sur le terrain et réduit le risque d’erreurs :

• 1. Mesurez l’existant : enregistrez le trafic, les RPS, le TTFB, le CPU, la RAM, le disque et les métriques de base de données.
• 2. Identifiez le goulet d’étranglement : le problème vient-il du CPU, de la base, du disque ou du réseau ? Décidez avec des données, pas avec des suppositions.
• 3. Validez le matériel : vérifiez que les cœurs CPU, la RAM, le NVMe et la vitesse du port correspondent à la charge.
• 4. Réglez le serveur web : ajustez les workers, le keepalive, la compression et les en-têtes de cache sur NGINX, Apache ou LiteSpeed.
• 5. Optimisez le runtime applicatif : revoyez PHP-FPM, OPcache, le process manager Node.js ou les paramètres du runtime utilisé.
• 6. Analysez la base de données : activez le slow query log, corrigez les index, ajustez le buffer pool et les limites de connexions.
• 7. Déployez la couche de cache : concevez ensemble le CDN, le cache de page, Redis et les politiques de cache navigateur.
• 8. Durcissez la sécurité : mettez en place WAF, rate limit, fail2ban, clés SSH et mises à jour régulières.
• 9. Installez supervision et alertes : suivez les métriques critiques dans un tableau de bord et recevez des notifications automatiques en cas de dépassement.
• 10. Effectuez un test de charge : validez les changements avec des scénarios réalistes et documentez les résultats.

Quand augmenter les ressources, et quand changer d’architecture ?

Tous les problèmes de performance ne se résolvent pas avec un serveur plus puissant. Si une seule requête bloque tout le système, une mise à niveau matérielle ne fera souvent que repousser le problème. En revanche, si les cœurs CPU sont constamment saturés, que la RAM est utilisée sainement, que les requêtes sont optimisées et que le cache fonctionne correctement, passer à un serveur dédié plus puissant devient logique. C’est ce qu’on appelle la mise à l’échelle verticale.

La mise à l’échelle horizontale consiste à répartir la couche web sur plusieurs serveurs, utiliser un load balancer, séparer la base de données, ajouter une read replica et servir les fichiers statiques via un CDN ou un stockage objet. Pour les grands projets e-commerce et médias, cette approche est souvent plus durable. Dans le plan de migration, il ne faut pas oublier les TTL DNS, les certificats SSL, la gestion des sessions, la synchronisation des fichiers et les procédures de sauvegarde.

À quoi faire attention en planifiant avec Hostragons ?

Le choix d’un serveur dédié ne doit pas seulement se baser sur le trafic d’aujourd’hui, mais aussi sur les objectifs de croissance des 6 à 12 prochains mois. Les périodes de campagne, le budget publicitaire, la saisonnalité, la progression SEO et les nouvelles fonctionnalités doivent être intégrés au plan de capacité. Sur Hostragons, en évaluant les ressources Serveur Loué adaptées à vos besoins, vous pouvez aussi planifier le bon parcours entre Requête de domaine pour votre nom de domaine, certificats SSL pour un trafic sécurisé et Hébergement web pour les projets en phase de démarrage.

Un serveur dédié bien optimisé apporte un chargement plus rapide des pages, un taux d’erreur plus faible, une infrastructure plus sûre et une meilleure expérience utilisateur. Du point de vue SEO, la vitesse, l’accessibilité et la stabilité sont aussi des signaux indirects mais importants. Dans les évaluations de Google centrées sur l’expérience utilisateur, les sites lents ou souvent indisponibles peuvent voir leurs performances organiques fragilisées.

Conclusion

L’optimisation d’un serveur dédié pour un site à fort trafic n’est pas un réglage ponctuel, mais un cycle continu de mesure, amélioration, test et supervision. En commençant par le bon choix matériel, puis en traitant ensemble le serveur web, l’application, la base de données, le cache, la sécurité et les alertes, vous pouvez obtenir beaucoup plus de rendement de la même infrastructure. Si vous souhaitez évaluer la capacité actuelle de votre serveur ou choisir une configuration adaptée à votre croissance, vous pouvez examiner les options de serveurs dédiés Hostragons et construire un plan de migration progressif selon vos besoins.

Questions fréquentes

Combien de temps prend l’optimisation d’un serveur dédié ?

Les premières mesures et optimisations de base peuvent souvent être réalisées en 1 à 3 jours. En revanche, l’analyse de base de données, les tests de charge, la stratégie de cache et les améliorations d’architecture peuvent nécessiter plusieurs semaines de travail planifié selon la complexité du site.

Combien de RAM faut-il pour un site à fort trafic ?

La réponse dépend de l’application. Pour des sites dynamiques de taille moyenne, 16 à 32 Go de RAM peuvent suffire au départ. Pour un e-commerce très actif, une grande base de données ou un projet utilisant Redis de manière intensive, 64 Go ou plus peuvent être un choix plus adapté.

NGINX ou Apache : lequel offre les meilleures performances ?

Avec un grand nombre de connexions simultanées, NGINX est généralement plus efficace. Apache garde toutefois des avantages en flexibilité et compatibilité. Avec PHP-FPM, un cache bien conçu et une configuration correcte, les deux solutions peuvent donner de bons résultats ; le choix doit dépendre des besoins de l’application.

Si j’utilise un CDN, ai-je encore besoin d’optimiser mon serveur dédié ?

Oui. Le CDN réduit la charge sur les contenus statiques et cacheables, mais les pages dynamiques, le paiement, l’espace membre, l’administration et les opérations de base de données dépendent toujours du serveur d’origine. Le CDN ne remplace donc pas l’optimisation serveur : il la complète.

Si mon serveur est lent, dois-je passer immédiatement à une offre plus puissante ?

Il faut d’abord mesurer le goulet d’étranglement. Le problème peut venir d’une mauvaise requête, d’un cache absent, d’un réglage PHP-FPM incorrect ou d’un trafic bot. Augmenter le matériel sans corriger ces causes augmente les coûts, mais ne règle pas forcément le problème à la racine.