Un catalogue en constante expansion peut mettre à rude épreuve la synchronisation API. Les tâches volumineuses peuvent ralentir, expirer ou s'interrompre prématurément. Pour gérer les limites de débit de l'API PrestaShop , divisez le travail en petites pages. Récupérez uniquement les champs nécessaires. Limitez le nombre d'appels simultanés. Enfin, sauvegardez la progression afin qu'une tâche interrompue puisse reprendre au bon endroit.
Il n'existe pas de taux de requêtes universel. Le taux optimal dépend de votre serveur, de votre base de données, de vos modules, de votre hébergement et de votre configuration réseau. Testez votre propre système plutôt que de copier un taux fixe d'un autre projet.
1.0 Que sont les limites de débit des API ?
Une limite de débit définit le nombre d'appels API qu'un client peut effectuer dans un laps de temps donné. Une passerelle peut comptabiliser les appels par seconde, minute ou heure. Si le client envoie trop d'appels, le service peut les retarder ou les refuser.
En pratique, les limitations de débit de l'API PrestaShop peuvent provenir de la boutique PrestaShop ou d'une autre couche de son infrastructure d'hébergement.
La taille de la requête est un problème distinct. Un appel peut demander un très grand volume de données. Cet appel peut consommer beaucoup de mémoire, de temps de base de données et de bande passante.
La solution dépend du problème :
- Les appels arrivant trop rapidement nécessitent un tarif plus bas et moins de travail en parallèle.
- Pour les réponses volumineuses, utilisez des pages, des filtres et moins de champs.
- Lorsque les deux problèmes surviennent, utilisez les deux ensembles de commandes.
2.0 Limites de débit de l'API PrestaShop : existe-t-il une limite fixe ?
PrestaShop ne publie pas de limite de requêtes par seconde unique pour l'ensemble des boutiques. Ne considérez pas une valeur aléatoire de requêtes par seconde comme une règle officielle de PrestaShop.
La limite peut provenir d'un autre élément de votre configuration. Apache, Nginx, un proxy, un pare-feu ou un hébergeur peuvent bloquer le trafic important. Un CDN, une passerelle, un module personnalisé ou une application cliente peuvent également définir une règle.
Vérifiez le statut HTTP, le corps et les en-têtes. Consultez ensuite les journaux de PrestaShop, du serveur et de toute passerelle de paiement. Les journaux de synchronisation doivent indiquer l'heure, la route, le statut et le temps de réponse.
Recherchez des schémas. L'erreur peut apparaître uniquement lorsque plusieurs processus sont exécutés simultanément. Des réponses volumineuses peuvent en être la cause. Dans d'autres cas, les défaillances surviennent après un certain nombre d'appels. Un délai d'attente dépassé ou une erreur HTTP 500 ne prouve pas que la limitation de débit soit à l'origine de la défaillance.
3.0 Pourquoi les requêtes API PrestaShop volumineuses causent des problèmes
Une liste volumineuse peut contraindre la base de données à exécuter une requête coûteuse. PHP a besoin de mémoire pour générer la réponse. Le serveur doit ensuite envoyer un fichier XML ou JSON volumineux.
Une requête volumineuse ayant échoué est difficile à récupérer. Le client peut avoir besoin de télécharger à nouveau la liste complète, ce qui augmente la charge.
Plusieurs requêtes importantes peuvent également entrer en concurrence avec les acheteurs. Le guide de performance de PrestaShop indique que la vitesse dépend de l'ensemble du système. La mise en cache, la conception de la base de données, les paramètres du serveur et les modules ont tous leur importance.
N'essayez pas d'envoyer la requête la plus volumineuse que votre serveur puisse traiter en une seule fois. Choisissez une unité plus petite qui fonctionne correctement à chaque fois. Il doit également être facile de la relancer.
4.0 Comment gérer les requêtes API volumineuses dans une boutique PrestaShop
4.1 Diviser les listes en pages
La pagination charge une longue liste par petits groupes. Une synchronisation lit un groupe, le traite, puis récupère le suivant. En cas d'échec, elle reprend à partir du dernier point de sauvegarde.
Cette méthode facilite la gestion des limites de débit de l'API PrestaShop car chaque unité de travail reste petite.
Le service web de PrestaShop 9 prend en charge une valeur limite sous la forme [offset,]limit . Son décalage initial est zéro. D'après le guide officiel, cette option peut être utilisée pour la pagination.
Figure 2. Exemple de pagination et de sélection de champs du service Web PrestaShop 7.
Figure 3. Exemple de pagination et de sélection de champs du service Web PrestaShop 8.
Figure 4. Exemple de pagination et de sélection de champs du service Web PrestaShop 9.
Choisissez la taille de page en effectuant des tests. Un hébergement mutualisé peut nécessiter des pages plus petites qu'un serveur dédié. Les données produit complexes peuvent également nécessiter des pages plus petites.
Conservez l'ordre de tri stable, car les enregistrements peuvent être modifiés lors d'une synchronisation longue. Une date de modification fiable ou un identifiant enregistré peuvent garantir des mises à jour plus sûres. Vérifiez les filtres et les champs de tri pris en charge par votre version de PrestaShop.
4.2 Demandez moins de champs
L' option d'affichage du service Web permet de renvoyer uniquement les champs sélectionnés. Utilisez-la lorsque la tâche ne nécessite que quelques valeurs. Par exemple, une synchronisation de stock peut ne pas exiger les descriptions complètes et autres détails sur les produits.
Les réponses plus courtes se chargent plus rapidement et consomment moins de mémoire. Testez d'abord les données produit complexes sur un environnement de test.
4.3 Synchroniser uniquement les éléments modifiés
Une importation complète est judicieuse lors de la configuration ou pour des vérifications ponctuelles. La plupart des tâches quotidiennes devraient éviter de relire l'intégralité du catalogue.
Lorsque les ressources le permettent, ne récupérez que les enregistrements nouveaux ou modifiés. Enregistrez le prochain point de contrôle après avoir sauvegardé la page actuelle. Si la tâche s'interrompt, elle pourra reprendre sans perte de données.
Supprimez les appels en double. Mettez en cache les données stables, comme les listes de pays, pendant une durée appropriée. Attribuez à chaque cache une durée d'expiration ou une règle d'actualisation claire.
5. Comment gérer une erreur HTTP 429
Le code HTTP 429 indique que le service considère qu'un client a envoyé trop de requêtes dans un laps de temps donné. Ce statut est défini dans la RFC 6585. La réponse peut inclure l'en-tête Retry-After , qui indique au client quand réessayer.
Figure 1. Exemple de réponse HTTP 429 avec en-têtes Retry-After et rate-limit.
Lors de l'analyse des limites de requêtes de l'API PrestaShop , considérez une erreur 429 comme un indice. Elle ne prouve pas que le noyau de PrestaShop ait défini cette règle.
Lorsque votre intégration reçoit une réponse 429 :
- Consignez l'itinéraire, l'heure, l'identifiant de la tâche, le statut et les en-têtes utiles.
- Suivre Réessayer après lorsque la valeur est présente et valide.
- Mettez en pause la tâche concernée au lieu de la réessayer immédiatement.
- Diminuez le taux d'appels ou le nombre de travailleurs si l'erreur se reproduit.
- Avertir l'équipe lorsque la tâche a épuisé toutes les tentatives autorisées.
Ne présumez pas que PrestaShop ait envoyé la réponse 429. Un proxy, une passerelle, un pare-feu, un hébergeur ou une API tierce peut en être la cause. Identifiez cette source avant de modifier le client.
6. Fonctionnement de la logique de nouvelle tentative et du délai d'attente
Certaines pannes sont de courte durée. Une connexion réseau peut être interrompue ou un serveur surchargé peut renvoyer une erreur. Une nouvelle tentative peut s'avérer utile, mais une tentative immédiate risque d'alourdir la charge.
Le délai d'attente (backoff) ajoute une période d'attente avant la nouvelle tentative. Si l'appel échoue à nouveau, le client patiente plus longtemps. Un court délai aléatoire peut empêcher plusieurs processus de se réveiller simultanément. Cette méthode est une pratique courante des API, et non une règle intégrée à PrestaShop.
Chaque processus de nouvelle tentative doit être limité. Définissez un nombre maximal de tentatives et un délai d'attente maximal. Ne relancez que les erreurs susceptibles de se résoudre d'elles-mêmes. Les identifiants de connexion incorrects, les droits d'accès insuffisants et les données invalides nécessitent une correction, et non des appels supplémentaires.
Soyez particulièrement vigilant lors des requêtes d'écriture. Le premier appel peut avoir modifié des données même si le client n'a pas reçu la réponse. Une nouvelle tentative à l'aveugle pourrait alors créer un doublon ou remplacer une valeur plus récente.
7. Bonnes pratiques concernant les limites de débit et les performances de l'API PrestaShop
Lors du réglage des limites de débit de l'API PrestaShop , utilisez plusieurs petits contrôles simultanément :
- Divisez les longues listes en pages et enregistrez un point de contrôle.
- Récupérez uniquement les champs et les enregistrements nécessaires à la tâche.
- Limitez le nombre de processus parallèles.
- Utilisez des délais d'attente de connexion et de réponse raisonnables.
- Mettre en cache les données à évolution lente et définir leur date d'expiration.
- Appliquer un recul limité aux échecs à court terme.
- Enregistrez les codes d'état, les temps de réponse, les tentatives de nouvelle connexion et la taille des pages.
- Surveillez la durée des tâches, le taux d'erreur, l'utilisation de la mémoire, la charge du serveur et le backlog.
- Effectuez des contrôles complets et approfondis en dehors des heures de pointe du magasin.
- Effectuez des tests avec une quantité réaliste de données avant la mise en production.
Ces étapes rejoignent les recommandations générales visant à paginer les listes volumineuses, à garantir la pertinence des réponses et à surveiller l'utilisation des API . Cependant, chaque paramètre doit être adapté aux données de votre boutique.
8. Exemple : Synchronisation d’un catalogue de produits volumineux
Imaginez une tâche qui télécharge les informations complètes de chaque produit. Elle lance de nombreux processus et ne sauvegarde aucune progression. Une requête expire, et la tâche redémarre. Elle télécharge alors les mêmes produits, inchangés, ce qui surcharge la plateforme.
Un meilleur système utilise une taille de page testée et ne demande que les champs nécessaires. Il stocke chaque page et enregistre un point de contrôle. La page suivante démarre dès que l'espace disponible le permet.
Après une erreur temporaire, le processus la consigne et attend. En cas de réponse 429, il suit les instructions de nouvelle tentative valides. Les exécutions suivantes ne récupèrent que les enregistrements modifiés, lorsque cela est possible. Une vérification complète planifiée permet de détecter les mises à jour manquées.
Cette conception peut envoyer moins d'appels par seconde. Pourtant, elle s'achève souvent de manière plus fiable car le travail est continu et facile à reprendre.
9. Créer une intégration PrestaShop plus fiable
Bien gérer les limites de débit de l'API PrestaShop commence par identifier la couche qui applique la limite. Déterminez ensuite si vous avez trop d'appels, trop de données, ou les deux.
Utilisez la pagination et la sélection de champs pour limiter la taille des réponses. Mettez en place une synchronisation basée sur les modifications, une mise en cache rigoureuse et des limites de processus pour réduire le trafic. Enfin, utilisez les journaux, la surveillance et un nombre limité de tentatives de récupération afin d'identifier clairement les erreurs et de faciliter la reprise en toute sécurité.
Avant de lancer une synchronisation à grande échelle, consultez les options de service Web disponibles pour votre version de PrestaShop. Testez l'ensemble de la tâche avec des données réalistes. Dans la plupart des cas, une petite tâche pouvant être reprise ultérieurement est plus sûre qu'une seule requête importante.
Pour des solutions PrestaShop fiables, le développement d'applications iOS et Android, la personnalisation et la migration de sites web, les propriétaires de boutiques peuvent nous contacter à l'adresse [email protected] . Ils peuvent également contacter notre service d'assistance.
