Kinsta est une plateforme d’hébergement réputée et très performante, construite sur Google Cloud. Bien que nous ne soyons pas le seul fournisseur d’hébergement à tirer parti de l’infrastructure de Google, nous sommes les seuls à placer nos clients sur les machines virtuelles les plus rapides disponibles dans chacun des 37 centres de données Google où nos serveurs sont situés.

Au début de l’année 2024, nous avons migré tous nos clients de l’hébergement WordPress infogéré vers les machines C3D de Google récemment mises à disposition dans tous les centres de données où ces machines virtuelles plus rapides étaient disponibles. Il s’agit de la mise à niveau la plus importante du matériel informatique de ce cloud depuis que nous avons adopté les VM optimisées pour le calcul basées sur C2 de Google en 2019.

Les C2 étaient alors les machines les plus rapides disponibles pour l’hébergement web et ont apporté un énorme gain de performance à la plateforme Kinsta. En fait, le C2 est toujours la machine la plus rapide dans la plupart des centres de données de Google. Nous déplacerons les clients vers les VM C3D dans d’autres centres de données lorsque Google les rendra disponibles.

Avant de déployer les machines C3D pour les clients de Kinsta, nous avons effectué des tests en laboratoire qui promettaient des améliorations réelles des temps de réponse des serveurs allant jusqu’à 50 %.

Ci-dessous, nous examinons les chiffres de certains tests effectués sur des sites WordPress réels.

Quelles sont les nouveautés des machines C3D de Google ?

Vous pouvez lire notre analyse approfondie de la technologie C3D, mais deux caractéristiques en particulier ont un impact considérable sur les performances des machines virtuelles :

  1. Un processeur AMD EPYC de quatrième génération (anciennement connu sous le nom de code « Genoa ») qui peut fonctionner à une fréquence de 3,7 GHz et prendre en charge jusqu’à 360 processeurs virtuels et 2 880 Go de mémoire DDR5.
  2. Une unité de traitement d’infrastructure (IPU) qui améliore les performances du réseau et des E/S de données tout en libérant le CPU de ces tâches.

Sur cette plateforme, le code côté serveur est interprété plus rapidement, les bases de données sont plus rapides et les données entrent et sortent des interfaces réseau à des vitesses plus élevées. Par exemple, lors de nos précédents tests en laboratoire, un test de stress MySQL/MariaDB a vu le délai de réponse aux requêtes de base de données passer de 89 millisecondes sur les machines C2 à 0,9 millisecondes sur une machine C3D.

Les sites WordPress hébergés chez Kinsta sont prêts à tirer parti d’une telle puissance, car chacun d’entre eux fonctionne dans un conteneur isolé des autres sites et comprend tous les logiciels nécessaires, tels que Linux, NGINX, PHP et MariaDB.

Comparaison des performances des VM

Pour comparer les performances de la VM basée sur le C3D avec d’autres classes de machines, nous avons créé trois sites WordPress (v6.5) identiques : un sur une machine C3D, un sur une C2, et un autre sur l’une des machines N2 encore disponibles dans quelques centres de données. (Bien que les machines N2 ne soient pas très utilisées chez Kinsta, beaucoup d’autres hébergeurs les utilisent. Nous avons donc inclus cette comparaison pour vous aider à visualiser l’impact que vous auriez sur les performances de votre site en passant simplement à Kinsta)

Voici l’environnement d’hébergement WordPress de Kinsta commun aux trois sites :

  • WordPress version 6.5
  • PHP version 8.2
  • Ubuntu version 20.04.6
  • Serveur web NGINX version 1.25.2
  • MariaDB version 15.1

Pour simuler de lourdes charges sur nos sites de test, nous avons utilisé l’outil d’évaluation comparative du serveur HTTP Apache ab, qui est capable d’émuler plusieurs utilisateurs simultanés effectuant de nombreuses requêtes de pages.

Requête de contenu non mis en cache

Nous voulions voir comment les trois machines virtuelles se comparaient lorsqu’elles fournissaient du contenu qui contournait les mécanismes de mise en cache sur le serveur, en particulier le cache de la page. Les paniers d’achat WooCommerce des sites identiques étaient les cibles parfaites pour ces tests puisqu’ils sont codés pour demander un contournement du cache sur le serveur.

Sans contenu mis en cache, WordPress doit interroger la base de données et construire la page cible à chaque requête. Ce n’est pas très efficace, mais c’est souvent nécessaire lorsque le contenu est unique pour un visiteur individuel – comme le contenu d’un panier d’achat.

Sur nos trois sites de test, l’affichage du panier par défaut générait une page HTML de 235 Ko.

Notre protocole de test Apache ab était donc le suivant :

  • Taille de la page : 235 Ko
  • Utilisateurs simultanés simulés : 50
  • Durée d’exécution : 60 secondes

Les résultats (requêtes réussies par seconde) :

  • C3D : 207.72
  • C2 : 141.47
  • N2 : 89.93

A retenir: La VM C3D a servi en moyenne 46,8 % de pages non mises en cache en plus que le site jumeau sur la C2.

Résultats des tests de vitesse des pages non mises en cache (cache-bypass).
Résultats des tests de vitesse des pages non mises en cache (cache-bypass).

Requête de contenu mis en cache

Avec la mise en cache activée, nos sites WordPress peuvent délivrer des pages sans avoir à lancer des workers PHP et à interroger la base de données. En fait, avec le cache en mémoire de NGINX, certains contenus compilés n’ont même pas besoin d’être lus sur le disque.

Notre contenu de test cachable était un article de blog identique sur chaque site qui pesait 114 Ko, notre protocole de test Apache ab était donc le suivant :

  • Taille de la page : 114 Ko
  • Utilisateurs simultanés simulés : 50
  • Durée d’exécution : 60 secondes

Les résultats (requêtes réussies par seconde) :

  • C3D: 19 722,58
  • C2: 13,043.27
  • N2: 7,861.23

A retenir: La VM C3D, avec ses E/S améliorées, s’est vraiment distinguée ici en déplaçant beaucoup plus de contenu plus rapidement que les autres machines. Le site C3D a délivré 51,2% de pages en cache en plus que la machine C2.

Résultats des tests de vitesse des requêtes de pages en cache.
Résultats des tests de vitesse des requêtes de pages en cache.

Un exemple de puissance de traitement brute

Nous avons utilisé la manipulation d’images pour tester des traitements sur nos machines virtuelles qui n’étaient pas directement liés à la livraison de pages web – bien que le redimensionnement des images téléversées et la réalisation de copies de différentes dimensions soient des procédures standard pour de nombreux sites WordPress.

Nous avons utilisé l’extension ImageMagick en PHP pour réduire une image JPEG de 35 Mo à environ 29 Ko (de 7 362 x 4 702 pixels à 640 x 408 pixels) en utilisant la fonction resizeImage() de ce logiciel et le filtre Bessel.

Les temps de traitement moyens qui en résultent :

  • C3D : 1,484 seconde
  • C2 : 2,090 secondes
  • N2 : 2,305 secondes

A retenir : Bien que le redimensionnement de l’image ait été relativement rapide sur toutes nos plateformes de test, la machine C3D a effectué la tâche près de 30 % plus rapidement que la machine C2 :

Résultats du test de vitesse de traitement d'image.
Résultats du test de vitesse de traitement d’image.

Pas de C3D dans votre centre de données ? Pas de problème !

Les C3D offrent des avantages évidents aux opérateurs de sites web WordPress. En particulier, si votre site génère du contenu qui ne peut pas être mis en cache, vous pouvez vous demander si ces avantages valent la peine de l’héberger dans l’un des centres de données supportant ces nouvelles machines.

Si une grande partie du contenu de votre site web peut être mis en cache, ces pages sont candidates à une distribution globale via le cache edge gratuit de Kinsta, l’un des services inclus dans notre intégration à Cloudflare.

Le cache edge peut être la meilleure solution en termes de performances pour les clients de Kinsta qui doivent installer leurs sites dans un pays où des machines virtuelles plus rapides ne sont pas disponibles.

Avec un contenu accessible par le cache edge distribué dans les centres de données de Cloudflare dans le monde entier, les temps de réponse des sites web sur nos machines de test C3D, C2 et N2 étaient pratiquement identiques lorsqu’ils étaient mesurés par le temps du premier octet (TTFB) à partir de différents emplacements externes.

Un échantillon des résultats du temps au premier octet avec le cache edge activé.
Un échantillon des résultats du temps au premier octet avec le cache edge activé.

Même avec le cache edge, la vitesse de réponse moyenne dans le temps peut être légèrement plus rapide avec les machines C3D puisque les sites hébergés sur ces machines peuvent remplir et rafraichir les caches plus rapidement.

Où pouvez-vous trouver les machines C3D ?

Actuellement, les machines C3D sont disponibles dans les 11 pays suivants

Centres de données de Google Cloud :

  1. Changhua County, Taiwan (asia-east1)
  2. Mumbai, India (asia-south1)
  3. Jurong West, Singapore (asia-southeast1)
  4. Sydney, Australia (australia-southeast1)
  5. St. Ghislain, Belgium (europe-west1)
  6. Frankfurt, Germany (europe-west3)
  7. Eemshaven, Netherlands (europe-west4)
  8. Council Bluffs, Iowa, USA (us-central1)
  9. Moncks Corner, South Carolina, USA (us-east1)
  10. Ashburn, Virginia, USA (us-east4)
  11. Las Vegas, Nevada, USA (us-west4)

Dans le tableau de bord MyKinsta, les régions où les machines C3D sont activées sont étiquetées comme Boostées dans le menu déroulant de l’emplacement du centre de données lors de l’ajout d’un nouveau site WordPress :

Les centres de données avec des machines C3D sont marqués comme boostés dans MyKinsta.
Les centres de données avec des machines C3D sont marqués comme boostés dans MyKinsta.

Si vous avez un site existant dans un centre de données où Google n’a pas encore rendu les machines C3D disponibles, vous pouvez contacter le support pour demander un transfert vers un centre de données C3D.

Pour l’instant, les VM C2 optimisées pour le calcul de Google sont les plus performantes dans ces centres de données :

  1. Changhua County, Taiwan (asia-east1)
  2. Hong Kong (asia-east2)
  3. Tokyo, Japan (asia-northeast1)
  4. Osaka, Japan (asia-northeast2)
  5. Seoul, South Korea (asia-northeast3)
  6. Mumbai, India (asia-south1)
  7. Delhi, India (asia-south2)
  8. Jakarta, Indonesia (asia-southeast2)
  9. Sydney, Australia (australia-southeast1)
  10. Melbourne, Australia (australia-southeast2)
  11. London, United Kingdom (europe-west2)
  12. Frankfurt, Germany (europe-west3)
  13. Zurich, Switzerland (europe-west6)
  14. Montréal, Canada (northamerica-northeast1)
  15. Toronto, Canada (northamerica-northeast2)
  16. São Paulo, Brazil (southamerica-east1)
  17. Columbus, Ohio, USA (us-east5)
  18. The Dalles, Oregon, USA (us-west1)
  19. Los Angeles, California, USA (us-west2)
  20. Salt Lake City, Utah, USA (us-west3)
  21. Las Vegas, Nevada, USA (us-west4)

Résumé

Nos tests suggèrent que le passage aux nouvelles VM C3D de Google, plus rapides, pourrait profiter à de nombreux propriétaires de sites web, en particulier ceux dont les sites diffusent du contenu qui ne peut pas être mis en cache.

Par rapport à nos machines C2 – qui étaient auparavant les plus rapides disponibles pour l’hébergement Web dans les centres de données de Google – les C3D se sont révélées plus rapides :

  • Une amélioration de la performance de près de 47 % dans les requêtes de pages non mises en cache
  • Une amélioration d’environ 52 % des requêtes de pages mises en cache
  • Une amélioration de 30 % du temps de traitement pour une tâche telle que le redimensionnement des images

N’oubliez pas : Les VM rapides comme l’éclair ne sont pas la seule chose que Google Cloud apporte à l’hébergement Kinsta. Nous profitons également du réseau Premium Tier à faible latence de Google.

En plus de son rôle dans le cache edge, Cloudflare est à l’origine de notre CDN ultra-rapide, de la minification du code, des Early Hints et de l’optimisation des images.

Trouvez chez Kinsta le pack d’hébergement WordPress infogéré qui vous convient.

Steve Bonisteel Kinsta

Steve Bonisteel est un rédacteur technique chez Kinsta qui a commencé sa carrière d'écrivain en tant que journaliste de presse écrite, chassant les ambulances et les camions de pompiers. Il couvre les technologies similaires à l'Internet depuis la fin des années 1990.