Ce document fournit des conseils de dépannage courants lors de la publication de messages dans un sujet Pub/Sub standard.
En savoir plus sur la publication de messages dans des sujets et sur les différentes fonctionnalités
Latence de publication élevée
La latence de publication correspond au temps nécessaire pour exécuter une requête de publication émise 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é sur Pub/Sub soit distribué à un client abonné. Il est possible que vous constatiez une latence de publication ou de bout en bout élevée, même lorsque la valeur de l'autre type de latence est faible. Une latence de publication élevée peut survenir au niveau du client éditeur Pub/Sub, en transit entre le client et le backend Pub/Sub, ou dans le backend Pub/Sub. Vous pouvez inspecter la latence de publication engendrée dans le backend Pub/Sub à l'aide de la métrique topic/send_request_latencies. La latence élevée de publication du backend peut être liée aux facteurs suivants:
Pub/Sub est conçu pour une diffusion à faible latence et à haut débit. Si le débit du sujet est faible, l'initialisation des ressources qui lui sont associées peut prendre plus de temps.
L'utilisation d'une règle de stockage des messages peut affecter la latence globale des requêtes adressées au sujet et à l'abonnement. Vérifiez les conséquences en termes de performances et de disponibilité de 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:
Assurez-vous de 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. Le lancement de nouveaux objets d'éditeur et l'ajout de nouveaux 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 vous constatez que les paramètres de nouvelle tentative par défaut ne sont pas suffisants pour votre cas d'utilisation, effectuez les ajustements correspondants. Vérifiez toutefois que les nouvelles valeurs ne sont pas trop élevées. Découvrez comment configurer des requêtes de nouvelle tentative.
Notez qu'une latence de publication élevée peut entraîner des erreurs DEADLINE_EXCEEDED. Celles-ci sont décrites 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 qui n'atteignent 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, regroupée 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. De plus, pour éliminer le risque 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 atteignent Pub/Sub, voici quelques causes possibles de l'échec des opérations de publication avec une 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, par exemple une mémoire insuffisante, une pression du processeur, un état de thread inadéquat ou l'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 vous aide à identifier un possible goulot d'étranglement dans votre système:
Vérifiez si vous publiez des messages plus rapidement que le client ne peut les envoyer. En général, 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 ont généralement une bande passante de 1 à 10 Mo/s, soit 1 000 à 10 000 messages par seconde. La publication de messages dans une boucle sans limitation du débit peut créer une brève utilisation intensive de la bande passante sur une courte période. Pour éviter cela, vous pouvez exécuter l'éditeur sur une machine dans Google Cloud ou réduire la fréquence de publication des messages en fonction de votre bande passante disponible.
Vérifiez si vous constatez une latence très élevée entre votre hôte et Google Cloud pour des raisons telles que l'encombrement du réseau de démarrage ou les pare-feu. Le calcul du débit du réseau fournit des indications pour déterminer votre bande passante et votre latence dans 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 des clients Cloud Pub/Sub pour maximiser les performances de traitement par flux montre comment Pub/Sub s'adapte sur une seule VM Google Cloud avec un nombre croissant de processeurs. Par exemple, vous pouvez atteindre 500 Mo/s à 700 Mo/s pour des messages de 1 Ko sur une instance Compute Engine à 16 cœurs.
Délai avant expiration de la publication inadéquat
Pour réduire le taux d'expiration des appels de publication, assurez-vous de définir un délai avant 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 un grand nombre de messages non envoyés en attente, des pics occasionnels de latence des requêtes peuvent entraîner l'expiration des appels de publication. Toutefois, si vos problèmes sont causés par un goulot d'étranglement persistant, et non 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 détectez un problème connu affectant la version de la bibliothèque cliente que vous utilisez, effectuez la mise à niveau vers la dernière version de la bibliothèque cliente. Vous avez ainsi bien récupéré toutes les mises à jour pertinentes, y compris les correctifs et les 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 publiés, ou ajustez le format des messages pour qu'ils correspondent 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 générer une 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, restaurez l'accès à la clé.