Quel hébergement de serveurs dédiés me faut-il pour un site à fort trafic ?

Comment dimensionner un serveur pour un site à fort trafic ?

Partez du pic de requêtes par seconde et de la durée de chaque requête, pas des visiteurs par mois. Multipliez les deux et vous obtenez le nombre de workers occupés à un instant donné. À 300 requêtes par seconde et 0,1 seconde chacune, 30 workers sont occupés en moyenne. Doublez ce chiffre pour les pics.

Ce n'est pas le nombre de visiteurs mensuels qui dimensionne un serveur, mais la minute la plus chargée.

• CPU. Une requête qui calcule utilise un cœur pendant son exécution. Les workers limités par le CPU ont besoin d'environ un cœur chacun. Les workers qui attendent une base de données ou une API peuvent être plus nombreux que les cœurs.
• Mémoire. Chaque worker a sa propre mémoire. Multipliez la valeur par worker par le nombre de workers, puis ajoutez le cache de la base de données et le système d'exploitation.
• Stockage. Les sites chargés sont souvent limités par leur base de données. Le NVMe local garde les requêtes et les logs hors des disques lents.

Lumenfer ne publie aucun benchmark : mesurez donc votre propre application. Testez une copie en charge avec un outil comme k6 ou wrk, et relevez la mémoire de pointe par worker dans top.

Combien de workers PHP-FPM, Node.js et nginx faut-il lancer ?

Fixez le pm.max_children de PHP-FPM d'après la mémoire, lancez un processus Node.js par cœur, et laissez nginx démarrer un worker par cœur.

• PHP-FPM. Le manuel PHP indique que pm.max_children limite le nombre de requêtes traitées simultanément. static maintient autant de processus enfants en marche ; dynamic et ondemand les démarrent à la demande. pm.max_requests relance les enfants après un certain nombre de requêtes, une solution pour les bibliothèques qui fuient.
• Node.js. Un processus Node.js exécute le JavaScript sur un seul thread. Le module cluster lance plusieurs processus qui partagent un port. L'exemple de sa documentation fork un worker par availableParallelism().
• nginx. Le manuel nginx considère qu'un processus worker par cœur CPU est un bon point de départ, et auto détecte ce nombre. worker_connections vaut 512 par défaut et compte aussi les connexions amont. La limite d'open-files plafonne ce réglage : augmentez donc worker_rlimit_nofile en parallèle.

# /etc/nginx/nginx.conf
worker_processes auto;        # one per CPU core
worker_rlimit_nofile 65535;   # open files per worker
events {
    worker_connections 8192;  # clients and upstreams together
}

# PHP-FPM pool, e.g. /etc/php/<version>/fpm/pool.d/www.conf
# pm = static
# pm.max_children = 64        ; free RAM for PHP / peak memory per child
# pm.max_requests = 1000      ; respawn children to contain leaks

Quelle bande passante consomme un site à fort trafic ?

Moins que vous ne le craignez une fois qu'un CDN sert les fichiers statiques, plus que vous ne l'imaginez sans CDN. Le Web Almanac 2025 du HTTP Archive situe la page d'accueil médiane à 2,86 Mo sur desktop et 2,56 Mo sur mobile. Ces chiffres proviennent de son crawl de juillet 2025. Les images et le JavaScript en constituent la plus grande part.

Le calcul pour une origine sans CDN :

• 1 To de trafic transporte environ 390 000 chargements mobiles de page d'accueil non mis en cache à 2,56 Mo.
• Un port 1 Gbit/s plafonne à 125 Mo par seconde : environ 49 de ces pages par seconde.
• Trente jours à pleine vitesse représentent environ 324 To.

Au poids médian d'une page, une seule origine 1 Gbit/s plafonne près de 49 chargements de page non mis en cache par seconde. Un CDN change la donne : l'origine n'envoie alors surtout que du HTML et des réponses API. Les offres Lumenfer vont de 30 TB par mois à 1 Gbit/s à 150 TB par mois à 1 Gbit/s. Le dépassement ne déclenche jamais de facturation automatique.

Faut-il un CDN devant un serveur dédié ?

Oui, pour tout site qui attend du vrai trafic : il décharge les octets statiques, absorbe les pics et s'interpose entre les attaquants et votre origine. La protection DDoS se limite à ce que le réseau du datacenter applique par défaut ; rien de plus n'est promis. Un flood envoyé vers l'unique adresse IPv4 du serveur atteint directement votre machine.

Ne publiez dans le DNS que les adresses du CDN et laissez l'origine n'accepter le trafic web que du CDN. Aucun journal n'est conservé : ni journaux de connexion, ni journaux de trafic, ni adresses IP de visiteurs ou de clients, ni sur le site, ni dans le tableau de bord, ni sur les serveurs. Un CDN que vous ajoutez conserve ses propres logs selon sa propre politique : lisez-la avant d'en choisir un.

Quel CPU convient à un site chargé : haut fréquence ou nombreux cœurs ?

Une fréquence élevée par cœur pour le temps de réponse, plus de cœurs pour les requêtes en parallèle. Une requête PHP ou Node.js s'exécute surtout sur un seul cœur : la vitesse de ce cœur fixe sa latence. Le nombre de cœurs fixe combien de requêtes tournent au même instant.

Les offres Ryzen associent moins de cœurs à des fréquences de type desktop. Les offres EPYC ajoutent des cœurs et de la mémoire ECC. Notre guide du meilleur CPU pour un serveur loué les compare, et le serveur le plus rapide que vous pouvez louer explique quels critères décident de la vitesse.

La base de données doit-elle tourner sur le même serveur que le site ?

Sur une seule machine, oui, tant que la base de données et les workers ne se disputent pas la RAM. Du matériel partagé garde les requêtes en local et ne coûte qu'une offre. Quand le cache de la base de données se retrouve à l'étroit, déplacez la base de données sur son propre serveur avec mémoire ECC, et reliez les deux en TLS.

Notre page sur le meilleur hébergement de serveur pour PostgreSQL couvre la mémoire, le stockage et les sauvegardes de cette seconde machine.

Quand un seul serveur ne suffit-il plus pour un site à fort trafic ?

Quand une heure d'indisponibilité coûte plus cher qu'un second serveur. Une machine, c'est un point de défaillance unique. Il n'y a pas de console IPMI ni KVM-over-IP pour les clients : vous demandez les redémarrages et les réinstallations dans le tableau de bord et l'équipe les exécute. Les sauvegardes ne sont pas incluses : conservez des copies de vos données ailleurs.

Pour la disponibilité, faites tourner un second serveur dans une autre ville avec réplication de base de données, et basculez via le DNS ou votre CDN. Amsterdam (Pays-Bas), Reykjavik (Islande), Zurich (Suisse) et Bucarest (Roumanie) : les cinq plans dans les quatre villes, un seul prix partout. Un serveur en veille à Zurich ou Reykjavik coûte exactement ce qu'il coûte à Amsterdam.

Dans le contrôle de Lumenfer sur 30 October 2026, 27 vendeurs de serveurs dédiés sur 34 facturaient leur serveur d'entrée de gamme avec un processeur antérieur à 2018. Chaque offre Lumenfer fait tourner un CPU de 2022 ou plus récent, de la DDR5 et du NVMe. Comparez le coût complet avec le cloud dans le bare metal est-il moins cher que le cloud, et voyez toutes les offres sur la page de tarifs Lumenfer.