Comment choisir l’hébergeur web le plus rapide en 2025 ?

Votre hébergement web est-il trop lent ?

Les choix technologiques et matériels de votre hébergeur impactent directement les performances de votre site web. Pourtant, la plupart des hébergeurs restent vagues sur leurs infrastructures et leurs performances réelles. En tant que client, vous en savez souvent pas ce pour quoi vous payez.

Chez LRob, nous essayons de faire mieux. Beaucoup mieux. Nous avons une approche transparente : nous mesurons, comparons et optimisons chaque paramètre, chaque choix matériel, pour garantir une vitesse de chargement jusqu’à 10x plus rapide que la concurrence. Nous tentons ainsi de vous proposer les hébergements web spécialisés WordPress les plus rapides. Et comme nous sommes fiers des résultats, nous n’avons aucun mal à vous les dévoiler.

Dans cet article, nous dévoilons donc nos benchmarks CPU et IOPS (SSD NVMe) pour vous expliquer comment nous choisissons nos serveurs. Nous vous montrerons ce qui fait vraiment la différence en matière de performances web.

Quels sont les critères d’un hébergeur web performant ?

Une infrastructure web comporte plusieurs éléments. Entre logiciels, matériel, choix d’infrastructure et politique de remplissage, de suivi, de lutte anti-robots… Tout cela va impacter la vitesse finale de votre site.

Si en tant que webmaster, vous avez très certainement votre rôle à jouer dans l’optimisation de votre site web (et LRob peut vous y aider), l’hébergeur joue un rôle central et auquel vous ne pouvez pas couper.

Décortiquons ce qui compose un serveur web, et l’impact sur les performances de chaque élément. Et voyons ce qu’il en est chez LRob.

Les composants logiciels

Les logiciels d’un serveur web ne sont pas si nombreux. Leur impact peut cependant être drastique sur les performances finales.

Voici donc un résumé des différents composants logiciels et de leur impact.

Serveur front(Apache, nginx, LiteSpeed…)

Il s’agit du serveur HTTP(S) en lui-même. Il communique avec l’extérieur directement et son support de nouvelles technologies comme HTTP/3 ou la compression Brotli peuvent améliorer la vitesse de chargement des visiteurs. Les serveurs nginx et LiteSpeed sont considérés comme les plus performants, là où Apache est le plus compatible.

• Chez LRob, nous combinons le meilleur des deux mondes, avec Apache en « back » et nginx en « front », via une astuce technique assez courante appelée « reverse proxy ». Cela permet de maximiser les performances et la compatibilité en même temps, tout en ajoutant le support d’HTTP/3 et la compression Brotli et la mise en cache des fichiers, grâce à nginx.

Configuration serveur front : Au delà du support ou non des nouvelles normes HTTP comme HTTP/3, deux critères principaux se démarquent : le nombre maximal de clients connectés en simultané, durée de vie d’une connexion. Cela détermine directement le nombre de visiteurs maximal supportés. D’autres critères comme le cache de fichiers nginx peuvent rentrer en jeu.

• LRob optimise intelligemment ces limites de sorte qu’elles aient la valeur maximale supportée par le matériel, sans saturer les ressources CPU ou RAM. La configuration permet également le cache de fichiers nginx en plus du cache système. Les valeurs peuvent être augmentées à la demande en fonction des cas spécifiques.

Serveur de base de données (MySQL, MariaDB)

La base de données est appelée à chaque visite de page sur le site. L’utilisation d’une version plus récente de MySQL ou MariaDB ainsi que de configurations optimisées amélioreront les performances. MariaDB est généralement considéré comme le plus libre et le plus performant. Les deux sont globalement inter-compatibles.

• Actuellement, les serveurs LRob utilisent MariaDB 10.11 et MariaDB 11.4.

Configuration du serveur de base de données : MySQL et MariaDB comportent de nombreux réglages, comme la taille maximale d’une requête ou la taille du cache en RAM. Aucun hébergeur ne communique sur cela. Pourtant, de bons réglages généreux en RAM peuvent décupler les performances de la base de données.

• Chez LRob, le buffer innodb est de 32Go minimum, ce qui permet d’inclure la quasi totalité des bases de données en RAM serveur pour des performances maximales.

Versions de PHP

Chaque nouvelle version de PHP est plus rapide que la précédente depuis quelques années. Si votre site et hébergeur sont compatibles, alors il faut toujours opter pour la version la plus récente pour des performances maximales.

• PHP 8.4 est la dernière version, déjà disponible chez LRob à l’heure de cet article.

Handler PHP (CGI, FastCGI, FPM, LSPHP…)

Le handler ou « connecteur » PHP fait le lien entre le serveur front et PHP. Celui-ci peut avoir un impact drastique sur les performances. FPM et LSPHP sont les deux plus performants.

• LRob utilise FPM avec une instance dédiée par site plutôt qu’une instance générale sur le serveur.

Configuration du handler PHP : Le handler PHP déterminera d’une part les limites de PHP en lui-même (par exemple la durée maximale d’exécution d’un script, ou la quantité de RAM maximale utilisable par un script), mais également le nombre de processus (threads) PHP simultanées qui peuvent tourner, qui détermine finalement le nombre de visiteurs maximal que vous pouvez servir en un temps donné – critère qui dépend aussi de la vitesse finale de votre site-.

• Chez LRob, les limites PHP dépendent de votre offre d’hébergement. Elles sont indiquées en toute transparence et sont dimensionnées en cohérence avec le dimensionnement de votre offre. A noter qu’un thread PHP-FPM sur un serveur puissant pourra servir davantage de pages par seconde que sur un serveur peu performant. Ainsi, même avec l’offre initiale LRob (Starter) qui offre seulement 2 FPM, vous pouvez, avec un site bien optimisé, servir plusieurs milliers de pages par minute (plus de 7500 pages/minute).

Support de Cache RAM

Support de cache RAM (Redis, memcached) : Si votre site et votre hébergeur sont compatibles, cela peut décupler les performances de votre site en stockant vos pages et requêtes en RAM serveur.

• LRob fournit un cache Redis en standard sur tous ses hébergements.

Composants hardware (matériels)

Le matériel derrière les serveurs web fait une différence majeure sur la vitesse de chargement finale. Plusieurs composants interagissent.

Le CPU

Le processeur des serveurs va directement déterminer la puissance de calcul disponible.

On peut résumer cela en 2 parties : La puissance « single thread », la puissance « multi-thread ». Autrement dit, la quantité de travail réalisable sur une tâche seule qui s’exécute sur un seul cœur de processeur, et la quantité de travail totale réalisable sur tous les cœurs de processeur en même temps.

Grossièrement, la puissance « single thread » détermine la vitesse de votre site lorsqu’il n’y a qu’un seul visiteur, tandis que la puissance « multi-thread » détermine le nombre de visiteurs maximal que vous pouvez accueillir. A noter que lorsque vous utilisez toute la puissance « multi-thread », vous réduisez plus ou moins la puissance « single-thread » en fonction du type de CPU utilisé, comme on le verra dans les benchmarks suivants.

• En 2025, LRob choisit des processeurs 12 à 16 cores (24 et 32 threads) chez AMD qui propose les meilleures performances brutes selon nos diverses mesures.

La RAM

La RAM stocke les programmes serveur et les calculs du CPU. Plus le serveur dispose de RAM, plus il pourra contenir de cache (MySQL, Redis, nginx, fichiers) et plus il pourra faire tourner de processus PHP. Là encore, cela affecte le nombre de visiteurs simultanés maximum et les performances obtenues.

• En 2025, LRob choisit des serveurs avec 128Go de RAM en standard, de quoi ne jamais être à court et profiter de mises en cache très généreuses pour éviter tout ralentissement.

L’IO du stockage

La capacité de stockage n’est pas un critère de rapidité sur un serveur web. On mesure plutôt les vitesses d’IO, c’est à dire d’input-output disque.

Toute lecture ou écriture de fichiers n’étant pas en RAM serveur utilisera de l’IO, que ce soit une requête MySQL ou la lecture des fichiers PHP et multimédia de votre site. Cela peut avoir un impact monumental sur la vitesse d’un site, surtout en ce qui concerne MySQL qui est généralement le plus sensible aux nombre d’opérations aléatoires chaque seconde (en particulier pour l’écriture, qui ne peut pas être mise en cache RAM).

Le disque dur classique est le plus lent, suivi des SSD en SATA, suivi des SSD NVMe qui sont les plus rapides. Dans le cas de serveurs virtualisés, les disques, quelle que soit leur forme, peuvent être déportés dans un SAN. Dans le cas d’un SAN, le stockage n’est alors plus local, pouvant entraîner une réduction des débits et une augmentation de la latence d’accès.

• En 2025, LRob choisit exclusivement des serveurs avec SSD NVMe en RAID local (le plus rapide disponible) pour ne jamais attendre les accès disque !

Choix d’architecture informatique

Deux types de serveurs existent chez vos hébergeurs :

• Les serveurs dédiés
  • LRob utilise uniquement des serveurs dédiés.
• Les serveurs virtualisés

Un serveur dédié est une machine physique « normale » qui accueille des services.

Un serveur virtualisé, est un sous-serveur crée à partir d’une machine plus grosse. On parle de « VPS » (virtual private server) ou de « VM » (virtual machine), comportant chacun son propre système d’exploitation. Cela donne une versatilité supérieure à l’hébergeur, mais coûte plus cher en RAM, en espace disque, et une baisse de performances peut avoir lieu en raison de la virtualisation et du nombre de systèmes à faire tourner.

Ensuite, on peut déployer les serveurs de différentes manières :

• Serveur LAMP (Linux Apache MySQL PHP) classique : Tout est sur la même machine (dédiée ou virtualisée)
  • LRob utilise uniquement des serveurs LAMP classiques et locaux sur serveurs dédiés.
• Cluster : On sépare chaque applicatif sur une machine différente (dédiées ou virtualisées)

La seconde méthode est plus versatile et peut permettre de supporter de plus gros trafics totaux et peut permettre des économies d’échelle sur les gros volumes avec potentiellement une redondance de service. Mais en contrepartie, complexifie l’architecture et elle peut avoir un coût important en performances. Car comme chaque machine est séparée, cela crée une latence due au réseau et aux différents protocoles utilisés, à chaque accès fichier, à chaque requête MySQL, à chaque exécution de PHP. De plus, les matériels utilisés sont généralement des processeurs avec de nombreux cœurs (32 et plus) mais une faible performance par cœur.

Utilisés à outrance, les clusters n’ont selon LRob de réelle nécessite qu’à partir de dizaines de milliers de visites par minute, par exemple pour les réseaux sociaux ou les sites de services d’état. Pour le commun des mortels qui possède un ou plusieurs sites web, les clusters auront pour principal effet de bien souvent réduire les performance.

D’autant plus que comme vous le verrez en toute fin d’article avec un test de charge sur le site « Copines de bons plans », on peut déjà faire plus de 12.000 visites par minute sur 2 process FPM chez LRob… Et bien plus sur les offres supérieures, pour peu que votre site soit très bien optimisé

Note : Bien que l’infrastructure LRob soit basée sur des serveurs dédiés, les offres que vous commandez sur le portail LRob sont bel et bien des offres mutualisées. Du mutualisé certes très performant, plus performant que ce que vous trouverez en VPS ou même sur serveur dédié à bas coût, mais techniquement ce sont bien des offres mutualisée, c’est à dire que plusieurs sites et utilisateurs sont sur la même machine physique.

Remplissage et blocage d’attaques : gestion de la charge serveur

La charge serveur, c’est l’utilisation moyenne de ressources des machines. Le but étant d’avoir une charge moyenne la plus faible possible, avec une réserve de ressources la plus haute possible. Cela permet que les serveurs supportent les pics de trafic, les pics de charge. Par exemple lorsque l’un de vos articles rencontre un fort succès sur les réseaux, ou qu’on parle de vous à la TV ou la radio, on cherche à tout prix à éviter la saturation serveur.

On devine bien souvent aux performances fluctuantes que les hébergeurs ont des serveurs plein à craquer, pour maximiser leur rentabilité. De plus, ils ne bloquent pas forcément efficacement les attaques de robots pirates, qui sur les sites à faible trafic peuvent représenter jusqu’à 95% de la charge. Imaginez, 95% des ressources de votre hébergement occupé par des robots… N’imaginez pas, c’est réellement ce qu’il peut se passer sans protection.

Et si la plupart des hébergeurs ne bloquent pas les robots, c’est à mon avis par choix stratégique : D’une part, cela incite les clients à passer sur serveur dédié ou offre supérieure (pour cause de lenteurs), et d’autre part, bloquer les attaques génère parfois des faux positifs, c’est à dire des clients qui se bloquent eux-même et feront donc une demande de support, que la plupart des hébergeurs n’ont pas envie de gérer.

En pratique, un serveur trop chargé comme on en voit souvent cause des lenteurs constantes ou occasionnelles sur votre site.

Chez LRob, on tente d’offrir les performances maximales à tout moment. Et pour cela, on applique une politique stricte :

• On se fixe l’objectif de ne pas dépasser les 25% de charge moyenne et 50% en pic. Si cela se produit : On diminue la charge à la source (blocage d’attaques ? optimisation d’un site ?) ou on migre les sites les plus lourds et/ou populaires vers une nouvelle machine.
• Blocage des attaques à différents niveaux, pour économiser jusqu’à 95% des ressources utiles, tout en protégeant vos sites web des attaques.
• Limites intelligentes des process FPM, de sorte qu’aucun site ne sature les serveurs
• Contact systématique des propriétaires de sites lents ou très populaires pour proposer des solutions d’optimisation des sites et ainsi réduire la charge serveur
• Monitoring 24/7 des performances serveur et intervention directe en cas d’anomalie

Performances matérielles : Le gap technologique

On l’a vu, le choix du matériel peut joue un rôle drastique sur les performances. Aujourd’hui, nous allons nous focaliser sur les deux éléments essentiels pour traduire les performances d’un site web : La puissance de calcul CPU, et les performances en lecture/écriture disque (IO).

Puissance de calcul (CPU)

Nous avons mesuré un panel assez varié de serveurs afin d’avoir une idée représentative de ce que l’on peut obtenir en fonction du type de serveur choisi.

Le test du jour : Geekbench 6.4, permet de se faire une bonne idée de la puissance de calcul des machines.

Cliquez ici pour en savoir plus sur les « cores » et les « threads ».

Les « cœurs CPU » ou en anglais « CPU cores » permettent chacun d’obtenir une puissance de calcul unitaire pour un programme qui ne serait capable d’utiliser qu’un seul core. Les processeurs modernes ont plusieurs cores. Lorsque l’on utilise tous les cores en même temps, les performances par core baissent (en raison d’autres facteurs limitants, comme la consommation électrique et les températures, la vitesse de la RAM, ou la vitesse des caches internes des CPU).

Pour savoir si une application est capable d’utiliser un ou plusieurs cores, on parle d’application « monothread » ou « multithread ». Certaines applications sont entre les deux.

MySQL est multithread.

Apache et nginx sont un mix single-multithread : chaque thread correspond à un chargement de fichier ou une session HTTP.

PHP est aussi un mix single-multithread : chaque thread correspond à l’exécution d’une page PHP (si plusieurs scripts sont appelés, ils resteront enfermés dans un thread). Autrement dit, un visiteur seul ne peut utiliser qu’un core CPU à la fois.

On comprend que pour les performances maximales, il faut au minimum 2 cores, sinon tous ces programmes devront se partager un seul core de CPU. Et si vous attendez de la visite, vous avez intérêt à avoir bien plus, et à choisir des cores performants !

Voici donc les machines qui passent à la moulinette du Benchmark aujourd’hui :

• VM 2 cores Intel Xeon chez PulseHeberg
• VM 2 cores Intel Xeon chez Hetzner
• VM 2 cores ARM chez Hetzner
• VM 4 cores AMD Epyc chez Hetzner
• Serveur dédié AMD Ryzen 9 3900 12 cores 24 threads chez Hetzner (serveur en production)
• Serveur dédié AMD Ryzen 9 5950x 16 cores 32 threads chez Hetzner
• Ordinateur personnel AMD Ryzen 9 5950x 16 cores 32 threads (pour contrôle, overclocking manuel 4.4Ghz fixe)
• VM 8 cores AMD Ryzen 9 9900x chez PulseHeberg

Et nous mesurerons trois valeurs :

• Les performances Single Thread, c’est à dire la puissance brute d’un seul core de processeur. Cela correspond aux performances lorsqu’une seule tâche a lieu (qui détermine la meilleure vitesse de chargement d’une seule page web lorsque le serveur est au repos).
• Les performances Multi Thread, c’est à dire la puissance totale supportée. Cela impacte le nombre de visiteurs simultanés maximum.
• Les performances par core en Multi Thread, c’est à dire les performances que vous pouvez espérer lorsque le serveur tourne à pleine charge. Cela est obtenu en divisant le résultat des performances Multi Thread par le nombre de cores CPU.

Les données brutes, avec en gras, les serveurs web mutualisés LRob :

CPU	Single	Multi	Per core	Lien	Remarques
VM 2 cores Intel Xeon E5-2680v4 PulseHeberg	817	1262	631	https://browser.geekbench.com/v6/cpu/10256420
VM 2 cores Intel Hetzner	749	1355	677,5	https://browser.geekbench.com/v6/cpu/10256916
VM 2 cores ARM Hetzner	1099	1975	987,5	https://browser.geekbench.com/v6/cpu/10256650
VM 4 cores Epyc Hetzner	1489	5012	1253	https://browser.geekbench.com/v6/cpu/10267600
Serveur Dédié 12 cores 24 threads AMD Ryzen 3900	1747	9345	778,7	https://browser.geekbench.com/v6/cpu/10256473	Serveur en prod, charge faible, résultat légèrement inférieur au réel
Serveur dédié 16 cores 32 threads AMD Ryzen 5950x	2273	12012	750,7	https://browser.geekbench.com/v6/cpu/10256332
PC Personnel Ryzen 9 5950X Desktop	2076	14209	888,	https://browser.geekbench.com/v6/cpu/10256353	Pour contrôle. Overclocking manuel 4.4Ghz & Watercooling
VM 8 cores AMD 9900X PulseHeberg	2877	11214	1401,7	https://browser.geekbench.com/v6/cpu/10256848	Rupture de stock

En graphique :

On peut tirer pas mal de conclusions.

Les performances single thread

Pour rappel, les performances en single thread vont directement affecter la vitesse perçue de votre site web. C’est le plus critique et souvent le plus négligé, car les hébergeurs classiques ont souvent tendance à choisir de très gros processeurs, avec de très nombreux cores, mais peu de performance single thread. Ainsi, ils peuvent accueillir de nombreux sites, mais individuellement, chaque site sera plus lent.

Et la différence peut être majeure, car nos mesures montrent que la vitesse va quasiment du simple au quadruple (x3.841) !

Le moins performant étant le single thread sur VPS Intel chez Hetzner, le plus performant étant le single Thread sur VPS AMD R9 9900X chez PulseHeberg. Ce dernier est cependant un OVNI dans le monde des VPS, offrant des performances défiant l’entendement (et malheureusement victime de son succès depuis sa sortie, avec des stocks très limités). Nous n’en tiendrons donc pas spécialement compte pour le moment, mais cela nous donne simplement des perspectives pour l’avenir.

Petite mention pour Pulseheberg qui a le mérite d’indiquer clairement sur son site que les hôtes de virtualisation utilisent des Intel Xeon E5-2680v4 (14 cores 28 threads, 2.4-3.3Ghz).

Les VPS en processeur ARM ont de beaux restes et passent devant nos VM Intel. Ils ne battent cependant pas AMD et ses fameux Epyc, mais il faut se rappeler qu’ARM propose un gain significatif en termes de consommation, ce qui n’est pas anodin pour un datacenter.

On voit d’ailleurs que les CPU Epyc sont quasiment 2x plus performants que les CPU Intel chez Hetzner, avec à l’arrondi, x1.99 d’amélioration.

En comparant le VPS le plus lent et les serveurs dédiés LRob, on voit qu’on est à x2.33 et x3.03 de gain de performances single thread pour respectivement les Ryzen 3900 et 5950x.

En partant du meilleur CPU disponible en virtualisé (AMD Epyc chez Hetzner) et en arrivant sur les dédiés LRob, on fait encore respectivement x1.17 et x1.52 de performances. A noter que le serveur avec un Ryzen 3900 étant en production lors du benchmark, ses performances mesurées sont inférieures aux performances réelles.

Performances en multi thread

En multi, on a deux manières d’appréhender les résultats : d’une part, les performances brutes, et d’autre part voir à quel point le gain est proportionnel au nombre de cores. Avec cette dernière approche, on peut avoir une idée de la puissance et de la saturation de l’hôte des VM. Car nous ne sommes jamais seuls dessus.

L’approche par « ratio »

Pour les VM 2 cores, où un score parfait serait un x2 en multi : chez PulseHeberg sur la VM 2 cores, on ne fait que x1.54 par rapport à son score single. Là où Hetzner nous fait du x1.8 sur sa VM 2 cores Intel. On peut imaginer que Hetzner a des CPU plus véloces sur ses hôtes ou un taux de remplissage moins important. De même que sur ARM avec x1.79, ce qui s’explique également par le nombre de cores importants des hôtes de virtualisation ARM.

En VM 4 cores, où un score parfait serait x4, Hetzner nous fait un respectable x3.36 sur la VM Epyc. Les CPU Epyc montant à 64 cores et plus tout en conservant une fréquence confortable, cela est très cohérent avec les attentes.

Côté dédié sur les Ryzen sélectionnés par LRob, on a du x5.3 les performances single, que ce soit sur le 3900 ou 5950x, où on s’attendrait à x12 ou x16.

Pour être exact, le 12 cores 24 threads Ryzen 3900 nous sort pile x5.3. Le 16 cores 32 threads Ryzen 5950x nous fait un x5.28. Alors pourquoi ça ne scale pas plus ? Car la fréquence CPU est fortement dynamique sur ces modèles. Ainsi, à faible charge, lorsque seulement quelques coeurs sont utilisés, on bénéficie d’une performance bien supérieure. Autrement dit, on obtient le meilleur résultat sur ces CPU en s’assurant de ne pas avoir une charge trop élevée.

En version desktop pour contrôle du 5950x (il s’avère que j’ai le même à la maison !), avec fréquence optimisée à la main, fixée à 4.4Ghz, on part d’un score single plus faible, mais en multi on fait finalement du x6.84. Résultat sensiblement supérieur au serveur, mais avec une consommation électrique également bien supérieure qui ne serait pas viable en datacenter.

Et pour la VM OVNI, la 8 cores sur Ryzen 9 9900X de PulseHeberg, celle-ci ne nous fait qu’un petit x3.89.. Mais à remettre en perspective, car les performances brutes restent exceptionnelles pour un 8 cores, dépassant le Ryzen 3900 (12 cores) et approchant les performances du Ryzen 5950x. De belles perspectives pour l’avenir.

Performances brutes

Voyons désormais la charge totale supportée par ces diverses machines.

Comparons la meilleure machine Intel dual core à nos dédiés :
Le Ryzen 3900 en prod fait 6.89x le score.
Le Ryzen 5950x, x8.86 le score.

Pour info, j’ai déjà vu des machines du type de ces 2 cores VM Intel héberger 50 sites sans trop de problème. Ce qui signifie qu’avec 7x les performances on pourrait héberger 350 sites. Cependant, on a fait le choix de s’arrêter autour de 200 à 250.

Face au plus véloce Epyc 4 cores :
Le Ryzen 3900 en prod fait 1.86x le score.
Le Ryzen 5950x fait 2.39x le score.

Performances par core

Sur les CPU de nos dédiés, les performances single core sont bien supérieures à la quasi totalité des serveurs, mais chutent en multi par rapport à ARM ou Epyc.

C’est un choix : En ne remplissant pas trop de tels serveurs, c’est ainsi que l’on obtient des performances drastiquement supérieures dans la vie de tous les jours, tout en ne s’écroulant pas totalement lors des forts pics de charges. Le but étant de faire en sorte que même les pics de charge soient sous les 50% d’utilisation totale.

Donc oui, on chute en performances par core… Mais d’un autre côté, on a un bien plus grand nombre de cores ! Moralité : Pour conserver les performances maximales, il faut faire en sorte de ne jamais arriver dans ce « worst case scenario » (et c’est ce que l’on fait chez LRob !).

Performances IO (lecture/écriture)

La vitesse d’IO est la vitesse de lecture et écriture sur le disque de votre serveur. Cela a un impact pour de nombreux éléments, mais MySQL (et MariaDB) est l’élément qui bénéficie certainement le plus d’un excellent IO. Et qui dit de meilleures performances MySQL, dit un site plus rapide, un processeur qui n’attend pas pour que les opérations disque se complètent, et finalement, des performances optimales.

Pour cette partie on a simplifié les tests pour des raisons pratiques en réduisant le nombre de machines testées à celles qui sont les plus pertinentes.

On utilise le benchmark Linux « fio ». La commande de benchmark utilisée nous produit 75% de lecture et 25% d’écriture, le tout en fichiers aléatoires de 4K :

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=fiotest --filename=testfio --bs=4k --iodepth=64 --size=8G --readwrite=randrw --rwmixread=75

Les valeurs brutes :

Server	Type	Read IOPS	Write IOPS	Read MB/s	Write MB/s
VM Intel PH	« Unités de stockage SSD RAID 10 »	14,2	4,7	58	19,4
VM ARM Hetzner	« highly available and reliable SSD-based storage »	41,4	13,8	169	56,6
Ryzen 3900 Hetzner	SSD NVMe RAID 5 soft	110	36,8	451	151
Ryzen 5950x Hetzner	SSD NVMe RAID 1 soft	114	38,1	467	156
9900x PH	« disques NVMe locaux »	121	40,5	496	166

Les débits obtenus en lecture/écriture simultanée :

Plus important encore, mais finalement assez proportionnel aux débits, le nombre d’opérations par seconde en lecture/écriture simultanée :

Que peut-on déduire ?

Comme beaucoup, PulseHeberg utilise probablement des SSD SATA classiques pour ses VM Intel, ce qui se traduit par le plus faible score ici. En revanche, sur les offres « Performance Cloud », ils ont manifestement sélectionné de bons disques NVMe, prenant la tête de ce benchmark.

Côté ARM et Hetzner, on est probablement en SSD NVMe ou en SATA avec carte contrôleur RAID. Les débits sont corrects mais sans plus. De plus, si un SAN est utilisé, alors ce débit peut varier au fil de la journée.

Sur serveur dédié avec RAID de SSD NVMe local, on obtient de très solides performances. La différence entre nos deux machines est de l’ordre de la marge d’erreur, probablement due au fait que le serveur à base de Ryzen 3900 soit en prod.

En écriture (le plus critique pour MySQL), on est 8.1x plus rapides que la machine la plus lente, et 2.76x plus rapides que la VM ARM d’Hetzner (qui fait déjà un score respectable pour un VPS).

En comparaison avec la plupart des offres de VPS que vous observez, la moyenne doit se situer entre ces deux-ci, avec des serveurs LRob autour de 5x plus rapides que la norme trouvable sur les VPS.

En pratique, cela se traduit par un serveur MySQL qui exécute les tâches rapidement et n’est jamais saturé, et par conséquent, des sites toujours les plus réactifs possibles. Dans l’absolu, nous n’avons jamais observé de saturation de l’I/O disque sur une telle configuration en utilisation normale.

Comment LRob choisit-il ses serveurs ?

Bien-sûr, le critère N°1 est la performance.

Les serveurs virtuels ayant des performances trop aléatoires sont hors de question pour la production web.

Pour répondre à nos exigences, les serveurs dédiés avec SSD NVMe et 128Go de RAM sont un pré-requis indiscutable.

Concernant les CPU, on choisit ceux qui ont les meilleures performances single core, tout en offrant de solides performances en multi.

Le partenaire principal choisi pour les serveurs LRob à ce jour est l’indétrônable Hetzner qui brille par son éco-responsabilité et la qualité de son support avec une équipe dans le datacenter en 24/7.

Pourquoi ne pas choisir des processeurs Epyc ?

Cette question est légitime. Avec un Epyc 32 cores ou plus, on obtiendrait une capacité totale bien supérieure. Mais ce serait un mauvais choix stratégique pour 3 raisons :

• D’une part, en charge modérée, nous obtenons de meilleures performances finales pour chacun des sites hébergés, en utilisant des Ryzen. En single core, notre 5950x est jusqu’à 1.52x plus performant qu’un Epyc.
• D’autre part, il y a le coût : les machines Epyc valent bien très cher, prenant donc davantage de temps à être amorties.
• Enfin, cela augmente le risque inutilement : rentabiliser une machine Epyc voudrait dire mettre énormément de sites dessus. Or, LRob pour la fiabilité et l’évolutivité, nous pensons qu’il vaut mieux avoir un peu plus de serveurs de taille moyenne que moins de gros serveurs. Au final on accueille déjà bien assez de sites sur Ryzen sans aucun ralentissement.

Pour le moment, ce n’est pas encore d’actualité, mais on garde bien-sûr un oeil sur les sorties de CPU et sur ce que les hébergeurs proposent.

Qu’en est-il du réseau ?

La consommation réseau est souvent surestimée, ou bien les lenteurs lui sont injustement attribuées. Un site lent ne signifie pas un réseau lent, les lenteurs proviennent plutôt d’un serveur lent, qui peine à générer les pages et/ou d’un site mal optimisé.

La moyenne d’utilisation réseau d’un serveur mutualisé dépasse rarement les 50Mbit/s, avec une moyenne autour de 10Mbit/s (merci aux webmasters de bien optimiser leurs sites !).

Or, tous les serveurs sont gigabit, donc 1000Mbit/s disponibles. On a de la marge… !

Au final, ce sont davantage les sauvegardes et les migrations, qui bénéficient de ces débits importants.

Quelles sont les performances chez LRob

En pratique, que donnent les performances de LRob par rapport aux autres hébergeurs ?

Sans pouvoir citer les hébergeurs source (légalement on peut être accusé de dénigrement), on peut cependant vous dire que LRob fait mieux que la quasi totalité des hébergeurs testés.

Nous avons migré des centaines de sites vers l’infrastructure LRob. Il est arrivé une seule fois que l’on observe pas de gain. Ce fut un événement historique et agaçant. Pour tous les autres cas, nous avons observé des sites qui chargent 2 à 10x plus rapidement, avec même des sites chargeant plus de 20x voire 30x plus vite après mise en place d’un cache ou réglage de celui-ci. Et le tout avec des vitesses stables au fil du temps.

Nous avons désormais une belle collection de graphiques avant/après migration dont voici un extrait :

Au final, comment être sûr de choisir l’hébergeur le plus rapide ?

Un bon moyen est de choisir l’hébergeur capable de transparence, comme nous le faisons ici.

Nous conseillons de prendre du recul sur les idées pré-conçues, sur le marketing et de regarder les mesures, les données réelles (matériel, architecture), voire encore mieux, d’effectuer vos propres mesures.

Chez LRob, nous faisons tout ce que nous pouvons pour que chacun puisse profiter des ressources maximales pour son site, à tout moment.

Au delà des choix matériels, la politique interne joue un rôle élémentaire également :

Une bonne gestion du taux de remplissage et un blocage efficace des attaques font des miracles. Aussi, en cas de pic, nous vérifions son origine et corrigeons si nécessaire avec le propriétaire de chaque site. Oui, nous prenons la peine de les contacter un par un. Et vous savez quoi ? Ça marche ! Car chacun est toujours heureux d’accélérer son site.

Au final, nous faisons en sorte de tourner autour de 20% de charge moyenne sur les CPU et 50% en pic, ce qui laisse une marge importante pour absorber les pics d’activité sans ralentissement.

Au lieu de trop remplir chaque serveur, nous considérons que le serveur ci-dessous est presque plein, nécessitant le déploiement d’une nouvelle machine pour les futurs clients :

Si vous trouvez que cette politique transparente est idéale et souhaitez en bénéficier pour vos sites internet, réservez dès maintenant votre hébergement LRob ! Et soyez parmi les premiers à profiter d’un hébergement sur un Ryzen 9 5950X avec SSD NVMe local !