Passer au contenu principal
Version : 1.x

Performances du serveur

Les performances du serveur ont un impact direct sur la vitesse et la réactivité de l’application WCPOS. Le POS effectue de nombreux appels API REST, donc le temps de réponse du serveur est le principal goulot d’étranglement — la vitesse du POS dépend fortement de la qualité de l’hébergement. Ce guide aide à surveiller, diagnostiquer et optimiser les performances du serveur à l’aide des métriques intégrées et des techniques de dépannage.

Configuration serveur minimale

Pour un POS réactif en production, nous recommandons au minimum :

CPU: 4 cœurs CPU ou plus
RAM: 4 Go ou plus
PHP: PHP 7.4+ (8.x recommandé)
Base de données: MySQL 8.0+ ou MariaDB 11.x
Stockage: SSD ou NVMe
SSL: HTTPS est requis — l’API REST WooCommerce ne fonctionnera pas sans HTTPS
L’hébergement mutualisé est souvent insuffisant

L’hébergement mutualisé dispose souvent de trop peu de workers PHP et de trop peu de mémoire pour les charges de travail POS, qui effectuent de nombreux appels API simultanés. Pour une utilisation du POS en production, un VPS ou un hébergeur WordPress infogéré est fortement recommandé. L’hébergement infogéré WordPress.com est également connu pour poser des problèmes de compatibilité avec l’API REST (certains utilisateurs ne voient que 9 à 10 produits dans de grands catalogues) — WordPress.org auto-hébergé est recommandé pour une compatibilité complète.

Pile d’optimisation validée par la communauté

Les utilisateurs signalent les meilleures performances POS avec cette combinaison :

  • MariaDB 11.4 (plus rapide que MySQL pour les charges de travail WooCommerce)
  • HPOS activé (voir ci-dessous)
  • Mise en cache d’objets LiteSpeed ou Redis
  • Stockage NVMe
  • PHP OPcache activé

Erreurs 503

Les erreurs 503 sont toujours côté serveur

Une erreur 503 Service Unavailable n’est pas un bug du POS — elle signifie que le serveur n’a pas pu traiter la requête. Vérifiez :

  1. La charge du serveur et les ressources disponibles
  2. Les workers PHP (ils peuvent être saturés)
  3. La limite de mémoire PHP : augmentez-la à 256 Mo ou plus
  4. Les journaux serveur de votre hébergeur web (contactez votre hébergeur ; il peut voir ce que l’application ne peut pas voir)

Compatibilité des versions de WooCommerce

Une mise à jour de WooCommerce peut parfois casser le POS. Mettez toujours WooCommerce à jour d’abord sur un site de préproduction, et gardez WCPOS à jour afin qu’il inclue les derniers correctifs de compatibilité.

Problèmes connus :

  • WooCommerce 10.5.0 — a cassé le chargement des produits dans le POS (symptôme : seuls environ 10 produits s’affichent ; la lecture de codes-barres et la recherche cessent de fonctionner) et a introduit un cache de produits expérimental qui peut provoquer un gonflement des postmeta et un épuisement de la mémoire. Correctif : mettez WCPOS à jour vers la dernière version (elle inclut le correctif et une migration de nettoyage), ou revenez à WooCommerce 10.4.3.

Si une mise à jour de WooCommerce casse le POS, revenez à la version précédente de WooCommerce (via l’onglet Avancé sur la page WordPress.org de l’extension) et signalez le problème.

Comprendre les métriques du serveur

WCPOS collecte automatiquement les métriques de performance du serveur à chaque opération de récupération de données (produits, commandes, clients, etc.). Vous pouvez consulter ces métriques dans l'écran Journaux.

Métriques serveur typiques

{
"total": "24692",
"execution_time": "76.64 ms",
"server_load": "[15.20605469,16.16357422,16.76806641]"
}

Décomposition :

  • total - Nombre d'enregistrements traités (24 692 ID de produits)
  • execution_time - Temps nécessaire pour terminer l'opération (76,64 millisecondes)
  • server_load - Charges moyennes du serveur sur 1, 5 et 15 minutes

Comprendre la charge du serveur

La charge du serveur représente la charge moyenne du système sur différentes périodes :

  • Première valeur - moyenne sur 1 minute (15.21)
  • Deuxième valeur - moyenne sur 5 minutes (16.16)
  • Troisième valeur - moyenne sur 15 minutes (16.77)

Interprétation de la charge

Les valeurs de charge du serveur peuvent être trompeuses et doivent être interprétées avec prudence :

Les valeurs de charge peuvent être trompeuses

Les moyennes de charge du serveur ne correspondent pas toujours directement aux performances. Un serveur avec des valeurs de charge élevées (15+) peut rester très réactif s’il dispose de ressources suffisantes et est correctement optimisé. Il faut se concentrer sur les temps d’exécution plutôt que sur les seules valeurs de charge.

Recommandations générales :

  • Charge relative aux cœurs CPU - une charge de 8.0 sur un serveur à 8 cœurs signifie une utilisation totale
  • Charge soutenue ou temporaire - De brefs pics sont normaux ; une charge élevée soutenue peut indiquer des problèmes
  • Les performances comptent davantage - Un serveur réactif avec une charge élevée vaut mieux qu’un serveur lent avec une faible charge

Points à surveiller :

  • Temps d’exécution en augmentation au fil du temps
  • Charge en hausse constante sans explication
  • Charge élevée ET temps d’exécution lents simultanément

Repères de performance

Recommandations sur les temps d’exécution

OpérationBonCorrectMédiocreCritique
Récupération des produits< 100ms100-500ms500ms-2s> 2s
Création de commande< 200ms200-800ms800ms-3s> 3s

Points à prendre en compte pour le nombre d’enregistrements

Le temps d'exécution doit évoluer de manière raisonnable avec le nombre d'enregistrements :

// Good scaling examples
{"total": "100", "execution_time": "15.2 ms"} // 0.15ms per record
{"total": "1000", "execution_time": "89.4 ms"} // 0.09ms per record
{"total": "10000", "execution_time": "234.1 ms"} // 0.02ms per record

// Poor scaling examples
{"total": "100", "execution_time": "500.0 ms"} // 5.0ms per record
{"total": "1000", "execution_time": "8000.0 ms"} // 8.0ms per record

Diagnostic des problèmes de performances

Étape 1 : surveiller les journaux

  1. Ouvrez Journaux depuis le tiroir de navigation
  2. Effectuez l'opération lente (synchronisation des produits, création d'une commande, etc.)
  3. Recherchez l'entrée de journal correspondante
  4. Développez le contexte pour voir les métriques

Étape 2 : analyser les métriques

Temps d'exécution élevé + charge serveur élevée = problème de ressources serveur

{
"total": "5000",
"execution_time": "3500.0 ms",
"server_load": "[12.45, 11.23, 10.87]"
}

Solution : augmenter les ressources serveur ou optimiser la configuration du serveur

Temps d'exécution élevé + charge serveur normale = problème d'extension/de base de données

{
"total": "1000",
"execution_time": "2800.0 ms",
"server_load": "[1.23, 1.45, 1.67]"
}

Solution : identifier les extensions lentes ou optimiser les requêtes de base de données

Temps d’exécution normal + charge serveur élevée = surcharge générale du serveur

{
"total": "2000",
"execution_time": "150.0 ms",
"server_load": "[8.90, 9.12, 8.45]"
}

Solution : réduire la charge serveur provenant d’autres processus ou augmenter les ressources

Problèmes de performance courants

1. Ressources serveur insuffisantes

Symptômes :

  • Charge serveur constamment élevée (> 4.0 sur la plupart des serveurs)
  • Temps d’exécution longs pour toutes les opérations
  • Délais d’expiration fréquents

Solutions :

  • Mettre à niveau le CPU - Des cœurs supplémentaires gèrent mieux les requêtes simultanées
  • Augmenter la RAM - Réduit les E/S disque et améliore la mise en cache
  • Utiliser un stockage SSD - Améliore considérablement les performances de la base de données
  • Optimiser les réglages PHP - Augmentez memory_limit, max_execution_time

2. Requêtes de base de données lentes

Symptômes :

  • Temps d’exécution élevés avec une charge serveur normale
  • Récupération des produits/commandes particulièrement lente
  • Codes d’erreur liés à la base de données dans les journaux

Solutions :

  • Activer WooCommerce HPOS - La plus grande amélioration possible des performances de la base de données
  • Utiliser la mise en cache des objets - Redis ou Memcached si votre hébergeur les propose
  • Maintenir WordPress à jour - Les mises à jour du cœur incluent souvent des optimisations de la base de données
  • Limiter les révisions d’articles - Ajoutez define('WP_POST_REVISIONS', 3); à wp-config.php

3. Interférence des extensions

Symptômes :

  • Dégradation soudaine des performances après les mises à jour des extensions
  • Certaines opérations sont beaucoup plus lentes que d’autres
  • Temps d’exécution élevés avec une charge serveur normale

Dépannage :

  1. Tester en préproduction - Désactiver toutes les extensions sauf WooCommerce et WCPOS
  2. Mesurer la référence - Enregistrer les temps d’exécution avec un minimum d’extensions
  3. Activer progressivement - Ajouter les extensions une par une afin d’identifier les responsables
  4. Vérifier les hooks des extensions - Rechercher les extensions qui se greffent aux actions WooCommerce

Extensions souvent problématiques :

  • Extensions SEO lourdes pendant les opérations sur les produits
  • Systèmes complexes de gestion des stocks
  • Extensions d’analyse/de suivi en temps réel
  • Extensions personnalisées mal codées

4. Configuration WordPress/WooCommerce

Symptômes :

  • Performances irrégulières
  • Erreurs liées à la mémoire dans les journaux
  • Tableau de bord d’administration lent

Liste de vérification d’optimisation :

  • Version de PHP - Utiliser PHP 8.0+ pour de meilleures performances
  • WooCommerce HPOS - Activer le stockage des commandes haute performance (voir ci-dessous)
  • Mise en cache WordPress - Activer la mise en cache objet si elle est disponible
  • Réglages WooCommerce - Optimiser les tailles des images de produits

Stockage des commandes haute performance WooCommerce (HPOS)

Gain de performance le plus important

HPOS est l’une des améliorations de performance les plus importantes que l’on puisse apporter à WooCommerce. Il stocke les commandes dans des tables de base de données personnalisées plutôt que dans la table des articles WordPress, ce qui améliore considérablement les performances des boutiques qui comptent de nombreuses commandes.

Avantages :

  • Requêtes de commandes plus rapides - Commandes stockées dans une structure de base de données optimisée
  • Charge réduite sur la base de données - Sépare les commandes des articles/pages
  • Meilleure évolutivité - Gère efficacement un grand nombre de commandes
  • Performances d’administration améliorées - Écrans de gestion des commandes plus rapides

Activation :

  1. Accédez à WooCommerce > Réglages > Advanced > Features
  2. Activez « Stockage des commandes haute performance »
  3. Suivre le processus de migration

En savoir plus :

Bonnes pratiques de surveillance du serveur

1. Contrôles réguliers des performances

  • Revues hebdomadaires - Vérifier les journaux pour repérer les tendances de performance
  • Mesures de référence - Enregistrer les temps d’exécution normaux
  • Surveillance aux heures de pointe - Surveiller pendant les périodes de fort trafic

2. Configurer des alertes de performance

Surveiller les signes d’alerte suivants :

  • Temps d’exécution constamment > 1000ms
  • Charge du serveur > 5.0 pendant des périodes prolongées
  • Erreurs de délai d’expiration fréquentes dans les journaux

3. Planification des capacités

Suivre les tendances de croissance :

  • Croissance du nombre d’enregistrements - Produits, commandes, clients
  • Dégradation des performances - Évolution du temps d’exécution
  • Utilisation des ressources - Utilisation du CPU, de la mémoire et du disque

Stratégies d’optimisation du serveur

1. Bonnes pratiques WordPress/WooCommerce

Activer HPOS :

  • L’amélioration des performances la plus déterminante pour WooCommerce
  • Consultez la section HPOS ci-dessus pour plus de détails

Configuration PHP (consultez votre hébergeur) :

memory_limit = 512M
max_execution_time = 300
max_input_vars = 3000

Configuration WordPress :

// In wp-config.php - limit post revisions
define('WP_POST_REVISIONS', 3);

// Enable WordPress debug logging if needed
define('WP_DEBUG_LOG', true);

2. Optimisations au niveau de l’hébergement

Mise en cache des objets :

  • Demandez à votre hébergeur si Redis ou Memcached sont disponibles
  • De nombreux hébergeurs WordPress infogérés le proposent automatiquement

Version de PHP :

  • Utilisez PHP 8.0+ pour bénéficier d’améliorations significatives des performances
  • La plupart des hébergeurs permettent de changer facilement de version de PHP

Ressources du serveur :

  • Assurez-vous de disposer d’une RAM suffisante (minimum 1 Go, de préférence 2 Go+)
  • Le stockage SSD offre de bien meilleures performances de base de données que les disques traditionnels

Remarques propres à l’hébergement

Certains hébergeurs et CDN nécessitent une configuration pour permettre au POS d’atteindre l’API REST WooCommerce :

Hébergeur / serviceProblèmeCorrectif
Service GoDaddyLe pare-feu du site web bloque les appels à l’API REST /wp-json/ (erreurs comme "Received 'undefined'")Website Security > Firewall > Réglages > Access Control > Allow URL Paths → ajouter /wp-json/
Hébergeur WP EngineL’API REST doit être explicitement activéeActiver l’API REST ; ajouter les points de terminaison API à la liste blanche dans leur pare-feu si nécessaire
Service CloudflarePeut bloquer les requêtes de l’API REST et mettre en cache les réponses APIVérifier les règles du pare-feu ; ajouter une règle de page pour contourner le cache pour /wp-json/*
Service WordPress.comProblèmes de compatibilité avec l’API REST / le chargement des produits (seuls 9 à 10 produits s’affichent)Utiliser WordPress.org auto-hébergé pour une compatibilité complète
Hébergement mutualiséTrop peu de workers PHP / mémoire insuffisante pour les appels POS simultanésMigrer vers un VPS ou un hébergeur WordPress infogéré

Les extensions de sécurité (Wordfence, etc.) peuvent bloquer l’API REST de manière similaire — consultez Conflits d’extensions pour la liste complète et les correctifs.

HTTP 414 — URI trop longue

Les paniers volumineux, ou le jeton d’accès inclus dans l’URL de paiement, peuvent dépasser la limite de longueur d’URL du serveur (la requête de paiement utilise GET). Ce problème peut dépendre du navigateur et être aggravé par le cache du navigateur.

Solution de contournement : vider d’abord le cache du navigateur, puis augmenter la limite de longueur d’URL du serveur :

  • Apache : LimitRequestLine 65536 dans httpd.conf
  • Nginx : large_client_header_buffers 4 65536; dans nginx.conf
  • Si vous n’avez pas accès à la configuration, demandez à votre hébergeur de l’ajuster.

Quand demander de l’aide

Contactez votre hébergeur ou un développeur WordPress si :

  • La charge serveur reste constamment > 8.0 malgré les efforts d’optimisation
  • Les temps d’exécution sont > 5000 ms pour des opérations simples
  • Des erreurs de mémoire apparaissent fréquemment dans les journaux
  • Les requêtes de base de données prennent constamment > 2 secondes

Fournissez-leur :

  • Les métriques serveur issues de vos journaux
  • La liste des extensions actives
  • Spécifications du serveur (CPU, RAM, type de stockage)
  • Versions de WordPress et WooCommerce