Les goulots d'étranglement du processeur sont un facteur de réduction des performances courant pour WooCommerce sites, en particulier lorsque le trafic augmente ou que les fonctionnalités dynamiques telles que le filtrage et les mises à jour du panier commencent à s'accumuler.
Dans nos tests de référence, Cloudways' nouvel hébergement optimisé pour le processeur (DigitalOcean) livré Des temps de réponse jusqu'à 84 % plus rapides dans les pires situations et une utilisation du processeur back-end réduite de 23 % par rapport à l'offre flexible standard. Pour 18 $ de plus par mois., les gains de performance sont évidents, surtout si vous exploitez une entreprise en pleine croissance ou sensible au trafic WooCommerce .
Contrairement aux blogs statiques ou aux sites de portfolio, WooCommerce fonctionne en mode dynamique, PHP- des pages lourdes qui peuvent facilement surcharger la puissance de traitement de votre serveur. Si votre page de panier est lente, votre paiement est bloqué ou votre panneau d'administration ne répond plus, vous êtes probablement confronté à une saturation du processeur.
Alors, que pouvez-vous faire?
Il existe trois manières principales de gérer les goulots d'étranglement du processeur. WooCommerce:
- Optimisez le code et les plugins de votre site pour réduire la charge du processeur.
- Utilisez la mise en cache avancée (si possible) pour décharger la génération dynamique.
- Passez à un plan d'hébergement qui vous offre une puissance CPU plus constante, comme Cloudways' nouvel hébergement optimisé pour le processeur pour DigitalOcean.
Dans cet article, nous allons expliquer à quoi ressemblent les goulots d'étranglement du processeur et comment les identifier. WooCommerce, et si Cloudways« L'offre optimisée pour le processeur vaut le coût supplémentaire. Nous avons testé les deux offres en utilisant le même WooCommerce site et une suite d'outils d'analyse comparative gratuits.
Creusons dedans
Pourquoi WooCommerce Les magasins sont-ils si sujets aux goulots d’étranglement du processeur ?
WooCommerce ne se comporte pas comme un animal typique WordPress Blog ou site de brochure. Presque chaque interaction, qu'il s'agisse de consulter un produit, d'utiliser des filtres ou de finaliser une commande, nécessite un traitement en temps réel. Cela signifie plus PHP exécution, plus MySQL requêtes et autres tâches en arrière-plan, qui consomment toutes du CPU.
Décomposons pourquoi WooCommerce est très gourmand en ressources CPU :
1. Panier et paiement dynamiques
Voici les points chauds CPU les plus évidents. Chaque fois qu'un client ajoute ou supprime un produit de son panier, met à jour une quantité ou passe à la caisse, cela déclenche des requêtes AJAX, des mises à jour de session et des calculs côté serveur (remises, taxes, frais de port). Ces pages ne peuvent pas être mises en cache, car elles sont uniques à chaque session utilisateur. Cela signifie que votre serveur les traite à chaque fois.
Lors d'événements commerciaux ou de lancements de produits, si des dizaines de clients passent en caisse simultanément, le processeur doit traiter chacun d'eux simultanément. Si votre processeur est partagé (comme avec les forfaits flexibles), vous atteignez rapidement une limite.
2. Filtrage des produits et requêtes de catalogue volumineux
Les pages de catégories de produits et les résultats de recherche ne sont souvent pas mis en cache, en particulier lorsqu'ils impliquent :
- Curseurs de prix
- Filtres d'attributs (taille, couleur, marque)
- Tri personnalisé (par exemple par note ou popularité)
Chacun de ces filtres génère une requête SQL dynamique en arrière-plan. Si votre boutique contient plus de 1,000 XNUMX produits, chaque requête peut solliciter lourdement le processeur et la base de données, surtout lorsque les filtres sont enchaînés.
3. WooCommerce Tâches d'arrière-plan
WooCommerce utilise un Planificateur d'actions pour exécuter des tâches telles que :
- Envoi d'e-mails de confirmation de commande
- Synchronisation des niveaux de stock
- Mise à jour des taux de change
- Nettoyage des sessions ou des paniers expirés
Ces erreurs s'exécutent même lorsque vous n'utilisez pas activement le site. Sans optimisation, elles s'accumulent et consomment silencieusement le processeur en arrière-plan. Un cas dans le Cloudways La référence a montré comment un plugin qui synchronisait les produits AliExpress sollicitait fortement le processeur, en effectuant plus de 100 mises à jour de produits toutes les quelques minutes.
4. Modules complémentaires multifournisseurs et d'adhésion
Les plugins comme Dokan, WCFM ou MemberPress augmentent la complexité en :
- Génération de tableaux de bord spécifiques aux fournisseurs
- Affichage des données individuelles des magasins
- Traitement des autorisations des utilisateurs
Chacune de ces actions peut charger des données, filtrer les commandes et exécuter une logique conditionnelle par utilisateur. Multipliez cela par des dizaines de fournisseurs ou des centaines de membres, et la demande en ressources CPU augmente rapidement.
5. Concurrence et verrouillage
Enfin, des WooCommerce doit maintenir l'intégrité transactionnelle :
- Deux clients tentent d'acheter le dernier article ? Le processeur et la base de données doivent le gérer en toute sécurité.
- Vérifications de verrouillage des stocks, validation des paiements, création de commandes : tout est géré de manière dynamique.
Cela entraîne des pics de CPU et des goulots d'étranglement possibles même sous une charge modérée, en particulier si la mise en cache est mal configurée ou sous-utilisée.
En bref, WooCommerce est conçu pour solliciter le processeur, surtout lorsque le trafic augmente. Ce n'est pas un code médiocre, c'est juste une charge de travail importante.
Comment savoir si vous rencontrez un goulot d'étranglement du processeur
Si votre site ralentit, il n'est pas toujours évident que le processeur soit le goulot d'étranglement. Cependant, certains schémas clairs suggèrent que c'est votre processeur qui est le point d'étranglement, et non la bande passante, le disque dur ou la mémoire.
Voici comment le repérer :
- Votre panier ou votre paiement est lent (alors que la page d'accueil fonctionne correctement) Les pages de panier et de paiement ne sont pas mises en cache et nécessitent un calcul en temps réel. Si ces pages se chargent lentement (même avec quelques utilisateurs seulement), c'est un signe évident que le processeur ne suit pas. Ajoutez un plugin comme Query Monitor et vous constaterez probablement de longs temps de chargement. PHP exécution ou lenteur MySQL requêtes sur ces pages.
- Le site ralentit pendant les pics de ventes ou de trafic Dix utilisateurs suffisent peut-être, mais lorsque 10 se connectent simultanément, votre boutique se bloque, ou pire, génère des erreurs de délai d'attente 30. Cela suggère des problèmes de concurrence, qui mettent en évidence les limites du processeur : votre puissance de traitement est insuffisante pour gérer le parallèle. PHP fils.
- Le panneau d'administration devient lent Si la modification des produits, la gestion des commandes ou l'accès aux rapports prennent trop de temps, ou si vous dépassez le délai d'attente lors de la modification en masse, votre back-end rencontre des difficultés. Il s'agit souvent d'un problème lié au processeur, surtout si votre boutique utilise des plugins qui enregistrent les vues, traitent les analyses ou gèrent les factures en arrière-plan.
- Cloudways La surveillance montre une utilisation élevée du processeur CloudwaysLe tableau de bord vous fournit des statistiques en temps réel sur l'utilisation du processeur et la charge moyenne. Si l'utilisation du processeur dépasse régulièrement 80-90 % lors des tâches de base, ou si votre charge moyenne dépasse le nombre de cœurs de votre processeur (par exemple, une charge moyenne supérieure à 2 sur un serveur à 2 cœurs), il s'agit d'une saturation du processeur. Vous pouvez également observer une ligne plate à 100 % de la charge du processeur sur votre graphique : cela signifie que le serveur est saturé et que des requêtes sont en attente (ou échouent).
- Vous remarquez un TTFB (temps jusqu'au premier octet) long Des outils comme WebPageTest or GTmetrix affichera un TTFB élevé (par exemple, > 500 ms) sur les pages dynamiques. Ce délai survient souvent avant le début du chargement de la page, ce qui indique généralement un temps de traitement CPU ou DB important. Si vous constatez des pics de TTFB uniquement sur les pages panier/paiement, mais pas sur les pages statiques, cela signifie que votre serveur est bloqué en direct. PHP exécution.
Notre configuration de test : hébergement flexible ou optimisé pour le processeur sur Cloudways
Cloudways a récemment lancé un nouveau plan optimisé pour le processeur en plus de DigitalOcean Infrastructure. Contrairement aux plans « Flexibles » existants (qui utilisent des vCPU partagés), l'option Optimisé CPU offre à votre site des cœurs de CPU dédiés que personne d'autre ne partage.
Pour tester si la mise à niveau en vaut la peine, nous avons créé un modèle identique WooCommerce site sur les deux Cloudways des plans:
| Plan | Processeur | RAM | Stockage | Tarifs et Prix |
|---|---|---|---|---|
| Cloudways Flexible (DO Premium) | 2 vCPU partagés | 4 GB | 80 GB NVMe | $ 54 / mo |
| Cloudways Optimisé pour le processeur (DO) | 2 vCPU dédiés | 4 GB | 25 Go SSD | $ 72 / mo |
Les deux sites utilisaient le même thème (Kiosko), un catalogue de produits factice et un ensemble de plugins identiques. Aucun plugin de mise en cache n'était requis. CDN des couches ont été ajoutées pour tester la puissance de traitement brute du backend sous charge.
Nous avons effectué trois séries de tests :
- Plugin WP Benchmark (pour les opérations CPU synthétiques)
- Chargeur.io (pour les utilisateurs simultanés simulés)
- WebPageTest (pour les mesures frontales telles que le TTFB et l'exécution du processeur)
Test 1 : WP Benchmark – Opérations CPU brutes
Le WordPress Plugin de référence d'hébergement simule différents types de traitement backend, y compris la gestion de données volumineuses et les calculs mathématiques.
Résultats
Le tableau suivant montre comment les deux plans sont comparés.
| Score de l'outil de référence WP | Cloudways Optimisé pour le processeur | Cloudways Flexible | Différences |
|---|---|---|---|
| Opérations avec des données textuelles volumineuses | 6.18 | 5.32 | 13.92 % |
| Opérations sur des données binaires aléatoires | 7.18 | 6.74 | 6.13 % |
| Calculs mathématiques récursifs | 4.71 | 4.69 | 0.42 % |
| Calculs mathématiques itératifs | 7.89 | 7.19 | 8.87 % |
| Opérations en virgule flottante | 4.49 | 3.85 | 14.25 % |
En résumé:
- Opérations à virgule flottante : L'optimisation du processeur a surpassé la flexibilité de 14.25 %
- Opérations avec des données textuelles volumineuses : 13.9 % plus rapide sur CPU-Optimized
- Calculs mathématiques itératifs et récursifs : 8 à 9 % plus rapide en moyenne
Dans toutes les catégories, le serveur optimisé pour le processeur a exécuté les tâches gourmandes en ressources processeur plus rapidement, même avec le même nombre de cœurs et la même RAM. La différence réside dans l'accès dédié ou partagé. Sur le serveur flexible, d'autres locataires peuvent également utiliser le processeur, ce qui entraîne des ralentissements imprévisibles.
Test 2 : Loader.io – Comment chaque forfait gère le trafic réel
Nous avons ensuite exécuté une simulation de charge de base en utilisant Chargeur.io pour envoyer 10,000 XNUMX clients au /shop/ page en une minute. Chaque plan a été testé avec le même scénario et le même timing.
Résultats:
| Tests de charge d'E/S du chargeur | Cloudways Optimisé pour le processeur | Cloudways Flexible | Différences |
|---|---|---|---|
| Temps de réponse moyen | 509 ms | 552 ms | -8.45% |
| Temps de réponse le plus long | 1857 ms | 3433 ms | -84.87% |
| Temps de réponse le plus court | 470 ms | 463 ms | 1.49 % |
En résumé:
- Temps de réponse moyen : L'optimisation du processeur était 8.45 % plus rapide (509 ms contre 552 ms)
- Temps de réponse le plus long : Amélioration massive : 1,857 3,433 ms contre 84.87 XNUMX ms (un gain de XNUMX %)
- Temps de réponse le plus court : À peu près la même chose (~470 ms)
La différence la plus significative ? La cohérence. Avec l'offre optimisée pour le processeur, les temps de réponse sont restés plus stables sous charge. Avec l'offre flexible, certaines requêtes ont subi d'importants retards, probablement parce que d'autres processus ou des « voisins bruyants » utilisaient des tranches de processeur partagées.
Test de 3: WebPageTest – Mesures du frontend du monde réel
Enfin, nous avons utilisé WebPageTest. Org pour simuler le comportement de navigation réel sur chaque site.
Résultats
| Test de page Web | Cloudways Optimisé pour le processeur | Cloudways Flexible | Différences |
|---|---|---|---|
| TTFB | 208 ms | 214 ms | -2.88% |
| Indice de vitesse | 1901 ms | 1586 ms | 16.57 % |
| Temps CPU total | 428 ms | 528 ms | -23.36% |
En résumé:
- Time to First Byte (TTFB): L'optimisation du processeur était légèrement meilleure (208 ms contre 214 ms)
- Indice de vitesse : Étonnamment meilleur sur Flexible (probablement en raison d'une mise en cache d'image ou de ressource légèrement différente)
- Temps CPU total du backend : L'optimisation du processeur utilise 23 % de temps de traitement en moins (428 ms contre 528 ms)
Les indicateurs TTFB et de temps CPU sont ici particulièrement importants. Ils montrent qu'en coulisses, le serveur optimisé CPU peut générer WooCommerce des pages plus rapidement et avec moins d'effort, même si la vitesse perçue par l'utilisateur final n'est que légèrement différente sous une charge légère.
Pourquoi le processeur dédié fait la différence pour WooCommerce
Alors, qu'est-ce qui rend l'hébergement optimisé pour le processeur meilleur pour WooCommerce?
- Vous ne partagez pas le processeur avec d'autres clients. Si quelqu'un d'autre sur le même hôte exécute une tâche gourmande en ressources, vos performances ne seront pas affectées.
- Des vitesses d'horloge plus élevées et plus constantes signifier PHP et MySQL les opérations se terminent plus rapidement.
- Concurrence plus prévisible: Vous pouvez servir plusieurs clients connectés (panier, compte, paiement) à la fois avant que les files d'attente ou les ralentissements ne commencent.
- Les processus d'arrière-plan n'interfèrent pas avec un trafic utilisateur en direct. Les e-mails programmés, les mises à jour des stocks et les importations s'exécutent plus rapidement et en parallèle.
Par exemple, lors de soldes de fin d'année ou d'un pic d'audience lié à un influenceur, votre site peut passer de 10 à 100 utilisateurs en quelques secondes. Avec un processeur partagé, les performances se dégradent rapidement. Avec un serveur dédié, vous gagnez de l'espace.
Quand devriez-vous passer à Cloudways« Plan optimisé pour le processeur ?
D'après nos tests et analyses, Cloudways« L'hébergement optimisé pour le processeur présente des avantages évidents, mais il n'est pas toujours nécessaire pour tous les WooCommerce magasin. L'essentiel est de savoir quand votre hébergement actuel devient un facteur limitant.
Effectuez une mise à niveau si :
- Votre L'utilisation du processeur atteint fréquemment 80 à 100 % in Cloudways' panneau de surveillance.
- Tu expérience panier lent, paiement ou performances d'administration, surtout sous trafic modéré.
- Vous courez plugins gourmands en ressources, tels que les plateformes multifournisseurs, les configurateurs de produits, la génération de factures ou les règles de tarification dynamique.
- Votre magasin doit rester réactif pendant périodes de forte concurrence—comme les ventes flash, le trafic généré par les influenceurs ou les événements saisonniers.
- Vous vous appuyez sur des processus d’arrière-plan (par exemple, cron jobs, synchronisation des données, facturation des abonnements) qui concurrencent le trafic frontal pour le temps CPU.
Dans ces cas, les avantages d’un accès CPU dédié — plus cohérent PHP exécution, moins de requêtes lentes et une meilleure concurrence — se traduisent directement par une expérience utilisateur plus fluide et un délai d'action plus rapide pour les clients.
Attendez si :
- notre magasin a trafic faible ou constant, et votre utilisation du processeur reste bien en dessous de 60 %.
- Vos problèmes de performances sont dus à goulots d'étranglement externes (par exemple, lent APIs, des plugins non optimisés ou des scripts tiers).
- Vous avez déjà atteint une bonne vitesse en utilisant la mise en cache, CDN, et l'optimisation des requêtes, et ne rencontrent pas de problèmes de concurrence.
En fin de compte, l'hébergement optimisé pour le processeur est un outil d'évolutivité, et non un remède miracle contre une mauvaise optimisation. Mais si vous utilisez un système performant, WooCommerce site et commencez à atteindre les plafonds de ressources, cette mise à niveau vous donne la marge de performance nécessaire pour évoluer en toute confiance.
Verdict : est Cloudways« L'hébergement optimisé pour le processeur en vaut-il la peine ?
Pour 18 $ de plus par mois, Cloudways« Le plan optimisé pour le processeur nous a donné :
- Jusqu'à 14 % de scores de référence backend améliorés
- Temps de réponse moyens 8 à 9 % plus rapides sous charge
- Stabilité du temps de réponse dans le pire des cas 84 % plus rapide
- 23 % de temps CPU en moins lors des chargements de pages complètes
Ces chiffres se traduisent par des expériences d'achat plus cohérentes, moins de temps morts et une plus grande confiance aux heures de pointe. Si votre WooCommerce le magasin commence à montrer des signes de tension, cette mise à niveau peut vous offrir une marge de performance sans avoir besoin de passer à un hébergement de niveau entreprise.
Ce n'est pas une solution miracle, mais c'est une étape intelligente et évolutive entre un VPS partagé à faible coût et un VPS entièrement géré. WooCommerce les plates-formes.
Essayez-le par vous-même
Vous voulez tester CloudwaysVous disposez d'un plan optimisé pour le processeur sur votre propre boutique ? Commencez par un essai ou utilisez leur nouvelle fonctionnalité de mise à l'échelle verticale pour mettre à niveau ou rétrograder votre instance en un clic.
Voir Plus Cloudways Hébergement optimisé pour le processeur
