La latence est le temps nécessaire pour recevoir la réponse à une requête. Ce guide fournit des ordres de grandeur de latence pour les requêtes Merchant API. Utilisez ces valeurs pour définir des délais avant expiration et planifier le débit de votre intégration.
La plupart des requêtes de l'API Merchant sont traitées en moins d'une seconde. La mise à jour de l'inventaire local et régional peut prendre quelques secondes, et certaines requêtes de rapport prennent beaucoup plus de temps.
Latences habituelles
Le tableau suivant indique les latences approximatives par type de requête. La latence standard est la médiane : la moitié des requêtes se terminent plus rapidement. Le 1%des requêtes les plus lentes prend autant de temps que ce qui est indiqué dans la dernière colonne, voire plus.
| Type de demande | Exemples de méthodes | Latence typique | 1% des requêtes les plus lentes |
|---|---|---|---|
| Lectures et écritures de produits | products.get, productInputs.insert, productInputs.patch, productInputs.delete |
100 à 600 millisecondes | Environ 2 secondes |
| La plupart des autres demandes | products.list, accounts.get, dataSources.list, aggregateProductStatuses.list |
Moins d'une seconde | Quelques secondes |
| Écritures d'inventaire locales et régionales | localInventories.insert, regionalInventories.insert et les méthodes delete correspondantes |
Quelques secondes | 10 secondes ou plus |
| Requêtes de rapport | accounts.reports.search |
Environ une demi-seconde | 30 secondes ou plus |
Les requêtes de rapport sont celles qui varient le plus. Leur latence dépend du tableau du rapport que vous interrogez et de la quantité de données couverte par la requête. Environ une requête de rapport sur dix prend généralement plus de deux secondes, et une petite fraction peut prendre plus d'une minute.
Recommandations
- Définissez des délais avant expiration avec une marge de sécurité. Si vous définissez des délais avant expiration des requêtes dans votre client, définissez-les bien au-dessus des latences les plus lentes répertoriées dans Latences types. Par exemple, un délai avant expiration de 60 secondes laisse une marge de manœuvre suffisante pour la plupart des requêtes, mais pas pour toutes les requêtes de rapport.
- Envoyez des requêtes indépendantes en parallèle. Étant donné que l'écriture d'un inventaire prend quelques secondes, l'envoi d'un inventaire après l'autre limite votre débit. Envoyez des requêtes indépendantes en parallèle ou utilisez des requêtes par lot. Lorsque vous envoyez plusieurs requêtes, tenez compte de vos limites par minute et quotidiennes. Pour en savoir plus, consultez la page Quotas de débit.
- Limitez les requêtes de rapport aux données dont vous avez besoin. Les requêtes qui couvrent de grands ensembles de données, comme de longues plages de dates, prennent plus de temps et peuvent expirer. Si vous avez besoin de grandes quantités de données, envisagez d'utiliser BigQuery. Pour en savoir plus, consultez Charger des données Google Merchant Center dans BigQuery.
- Réessayez avec un intervalle exponentiel entre les tentatives. Si une requête expire ou échoue avec une erreur temporaire, réessayez avec un intervalle exponentiel entre les tentatives.
Temps de traitement
Pour les requêtes qui modifient des données, une réponse positive signifie que l'API Merchant a accepté la modification, mais le traitement se poursuit après la réponse. Le temps de traitement correspond au délai entre la réponse et le moment où la modification est visible dans d'autres ressources. Le temps de traitement ne fait pas partie de la latence et peut être beaucoup plus long. Par exemple, il peut s'écouler quelques minutes avant que le produit traité ne reflète une entrée de produit insérée.
Pour en savoir plus sur l'état final de vos données, consultez les guides suivants :