Ce document fournit des conseils de dépannage courants pour la publication de messages. dans un sujet Pub/Sub standard.
Découvrez comment publier des messages dans des sujets et les différentes fonctionnalités.
Latence de publication élevée
La latence de publication correspond au temps nécessaire pour traiter une requête de publication envoyée par un client éditeur. La latence de publication est différente de la latence de distribution de bout en bout, qui correspond au temps nécessaire pour qu'un message publié dans Pub/Sub soit distribué à un client abonné. Vous pouvez observer une latence de publication élevée ou une latence de bout en bout, même si la valeur de l'autre type de latence est faible. Une latence de publication élevée peut être enregistrée au niveau du client éditeur Pub/Sub, lors de l'acheminement entre le client et le backend Pub/Sub, ou dans le backend Pub/Sub. Vous pouvez inspecter la latence de publication encourue dans le backend Pub/Sub à l'aide de la métrique topic/send_request_latencies. Une latence élevée de publication sur le backend peut être liée aux facteurs suivants:
Pub/Sub est conçu pour une distribution à haut débit et faible latence. Si le débit du sujet est faible, l'initialisation des ressources qui lui est associées peut prendre plus de temps.
Si vous utilisez une règle de stockage des messages, cela peut affecter la latence globale des requêtes adressées au sujet et à l'abonnement. Vérifiez les conséquences sur les performances et la disponibilité liées à l'utilisation de cette configuration.
Si votre client éditeur constate une latence de publication nettement supérieure à celle indiquée dans la métrique, cela peut être dû à l'un de ces facteurs côté client:
Veillez à ne pas créer un éditeur pour chaque publication. Il est recommandé d'utiliser un seul client éditeur par sujet et par application pour publier tous les messages. La création d'objets d'éditeur et l'ajout de threads entraînent des coûts de latence. Si vous utilisez Cloud Functions pour publier des messages, notez que les appels peuvent également affecter la latence de publication.
Si les paramètres de nouvelle tentative par défaut ne sont pas suffisants pour votre cas d'utilisation, effectuez les ajustements correspondants. Toutefois, vérifiez que les nouvelles valeurs ne sont pas trop élevées. Découvrez comment configurer les nouvelles tentatives de requêtes.
Notez qu'une latence de publication élevée peut entraîner des erreurs DEADLINE_EXCEEDED, qui sont abordées dans la section suivante.
Échec des opérations de publication avec erreur DEADLINE_EXCEEDED
Une erreur DEADLINE_EXCEEDED lors d'une requête de publication indique que celle-ci n'a pas abouti dans le délai imparti. Cela peut être dû à différents facteurs, tels que les requêtes n'atteignant pas le service Pub/Sub ou des problèmes de performances affectant les requêtes.
Pour vérifier que les requêtes de publication atteignent le service Pub/Sub, surveillez le sujet à l'aide de la métrique topic/send_request_count, dont les données sont regroupées par response_code. Cette métrique vous aide à déterminer si les requêtes échouent avant d'atteindre le sujet Pub/Sub. Si la métrique est vide, un facteur externe empêche les messages d'atteindre le service Pub/Sub. En outre, pour éliminer l'éventualité d'un problème intermittent, vérifiez le taux d'erreur. Si le taux d'erreur est très faible, il peut s'agir d'un problème intermittent.
Si les requêtes parviennent à Pub/Sub, voici quelques causes possibles de l'échec des opérations de publication avec l'erreur DEADLINE_EXCEEDED:
Goulot d'étranglement côté client
Les échecs de publication sont probablement causés par un goulot d'étranglement côté client, tel qu'une mémoire insuffisante, une pression du processeur, un mauvais état des threads ou un encombrement du réseau dans la VM hébergeant le client éditeur. Si un appel Publish renvoie DEADLINE_EXCEEDED, il est possible que les appels Publish asynchrones soient mis en file d'attente plus rapidement qu'ils ne sont envoyés au service, ce qui augmente progressivement la latence des requêtes. Vérifiez également si l'un des éléments suivants permet d'identifier un éventuel goulot d'étranglement dans votre système:
Vérifiez si vous publiez des messages plus rapidement que le client ne peut les envoyer. Généralement, chaque appel
Publishasynchrone renvoie un objetFuture. Pour suivre le nombre de messages en attente d'envoi, stockez le nombre de messages à envoyer avec chaque appelPublishet supprimez-le uniquement dans le rappel de l'objetFuture.Assurez-vous de disposer d'une bande passante d'importation suffisante entre la machine sur laquelle l'éditeur s'exécute et Google Cloud. Les réseaux Wi-Fi de développement disposent généralement d'une bande passante de 1 à 10 Mo/s, ou de 1 000 à 10 000 messages classiques par seconde. La publication de messages dans une boucle sans limitation du débit peut créer une courte utilisation intensive de bande passante sur une courte période. Pour éviter cela, vous pouvez exécuter le diffuseur sur une machine dans Google Cloud ou réduire la fréquence à laquelle vous publiez les messages pour qu'elle corresponde à votre bande passante disponible.
Vérifiez si vous constatez une latence très élevée entre votre hôte et Google Cloud pour l'une des raisons comme l'encombrement du réseau au démarrage ou les pare-feu. Le calcul du débit du réseau vous aide à déterminer la bande passante et la latence pour différents scénarios.
À terme, le volume de données pouvant être publiées sur une seule machine est limité. Vous devrez peut-être essayer d'effectuer un scaling horizontal ou exécuter plusieurs instances du client éditeur sur plusieurs machines. Tester les clients Cloud Pub/Sub pour maximiser les performances de streaming montre comment Pub/Sub évolue sur une seule VM Google Cloud avec un nombre croissant de processeurs. Par exemple, vous pouvez atteindre de 500 Mo/s à 700 Mo/s pour des messages de 1 Ko sur une instance Compute Engine à 16 cœurs.
Le délai avant expiration de la publication est inapproprié
Pour réduire le délai d'expiration des appels de publication, assurez-vous d'avoir défini un délai d'expiration suffisamment long dans les paramètres de nouvelle tentative du client éditeur. Pour les paramètres de nouvelle tentative, définissez le délai initial sur 10 secondes et le délai total sur 600 secondes. Même si vous n'accumulez pas de messages non envoyés en attente, les pics occasionnels de latence des requêtes peuvent entraîner l'expiration des appels de publication. Toutefois, si les problèmes sont causés par un goulot d'étranglement persistant, plutôt que par des délais d'inactivité occasionnels, de nouvelles tentatives peuvent entraîner davantage d'erreurs.
Problèmes liés à la bibliothèque cliente
Vous exécutez peut-être une version de la bibliothèque cliente avec un problème connu. La liste suivante inclut les outils de suivi des problèmes pour toutes les bibliothèques clientes. Si vous constatez un problème connu affectant la version de la bibliothèque cliente que vous utilisez, effectuez une mise à niveau vers la dernière version de la bibliothèque cliente. Vous avez ainsi accès à toutes les mises à jour pertinentes, y compris aux correctifs et aux améliorations des performances.
C++
C#
Go
Java
Node.js
PHP
Python
Ruby
Problèmes de schéma
Si vos publications commencent à renvoyer INVALID_ARGUMENT, il est possible que quelqu'un ait mis à jour le sujet pour modifier le schéma associé, supprimé le schéma ou supprimé les révisions de schéma associées au sujet. Dans ce cas, mettez à jour les paramètres du schéma du sujet avec un schéma et un ensemble de révisions correspondant aux messages en cours de publication, ou ajustez le format du message pour qu'il corresponde au schéma actuel.
Problèmes de chiffrement des messages
Si vous avez configuré votre sujet Pub/Sub pour chiffrer les messages publiés à l'aide d'une clé de chiffrement gérée par le client, la publication peut échouer et renvoyer l'erreur FAILED_PRECONDITION. Cette erreur peut se produire si la clé Cloud KMS est désactivée ou si les clés gérées en externe via Cloud EKM ne sont plus accessibles. Pour reprendre la publication, rétablissez l'accès à la clé.