Ce document fournit des conseils de dépannage courants lorsque vous publiez des 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 émise par un client éditeur. La latence de publication est distincte 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 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 être générée 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 dans le backend Pub/Sub à l'aide de la métrique topic/send_request_latencies. Une latence de publication backend élevée peut être liée aux facteurs suivants:
Pub/Sub est conçu pour la diffusion à faible latence et à haut débit. Si le débit du sujet est faible, l'initialisation des ressources associées peut prendre plus de temps.
Si vous utilisez une règle de stockage des messages, elle peut avoir une incidence sur la latence globale des requêtes envoyées au sujet et à l'abonnement. Consultez les implications en termes de performances et de disponibilité de cette configuration.
Si le client éditeur constate une latence de publication nettement supérieure à celle reflétée dans la métrique, cela peut être le signe de l'un des facteurs côté client suivants:
Assurez-vous de ne pas créer un éditeur pour chaque publication. Nous vous recommandons 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 un coût de latence. Si vous utilisez des fonctions Cloud Run 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. Toutefois, vérifiez que les nouvelles valeurs ne sont pas trop élevées. Découvrez comment configurer les requêtes de nouvelle tentative.
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 la requête n'a pas pu être traitée dans le délai imparti. Cela peut être dû à divers facteurs, par exemple si les requêtes n'atteignent pas le service Pub/Sub ou si des problèmes de performances les affectent.
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. En outre, pour exclure la possibilité d'un problème intermittent, vérifiez le taux d'erreur à l'aide du graphique de métrique topic/send_request_count mentionné précédemment ou de la page API et services de la console Google Cloud. 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 d'échec des opérations de publication avec une erreur DEADLINE_EXCEEDED:
Goulot d'étranglement côté client
Les échecs de publication sont probablement dus à un goulot d'étranglement côté client, tel qu'une mémoire insuffisante, une pression sur le processeur, un mauvais état de thread ou un encombrement du réseau dans la VM hébergeant le client de l'é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 permet de déterminer un goulot d'étranglement possible 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 de transfert suffisante entre la machine sur laquelle l'éditeur est exécuté et Google Cloud. Les réseaux Wi-Fi de développement ont généralement une bande passante comprise entre 1 et 10 Mo/s, soit 1 000 à 1 0000 messages par seconde. La publication de messages en boucle et sans limitation du débit peut générer une courte période d'utilisation intensive de bande passante. Pour éviter cela, vous pouvez exécuter l'éditeur sur une machine dans Google Cloud ou réduire la vitesse à laquelle vous publiez les messages pour correspondre à votre bande passante disponible.
Vérifiez si la latence entre votre hôte et Google Cloud est très élevée 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 permet de déterminer la bande passante et la latence adaptées à 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 de procéder au scaling horizontal ou d'exécuter plusieurs instances du client éditeur sur plusieurs machines. La section Tester les clients Cloud Pub/Sub pour optimiser les performances de diffusion montre comment Pub/Sub évolue sur une seule VM Google Cloud avec une augmentation du nombre de processeurs. Par exemple, vous pouvez atteindre 500 Mo/s à 700 Mo/s pour les messages de 1 Ko sur une instance Compute Engine à 16 cœurs.
Durée du délai avant expiration de la publication insuffisante
Pour réduire le taux d'expiration des appels de publication, assurez-vous que le délai avant expiration est assez 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 avant expiration total sur 600 secondes. Même si vous n'accumulez pas un volume important 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 plutôt que par des délais avant expiration occasionnels, des tentatives plus fréquentes peuvent entraîner davantage d'erreurs.
Problèmes liés aux bibliothèques clientes
Vous exécutez peut-être une version de la bibliothèque cliente qui présente un problème connu. La liste suivante inclut les outils de suivi des problèmes pour toutes les bibliothèques clientes. Si vous rencontrez un problème connu affectant la version de la bibliothèque cliente que vous utilisez, passez à la dernière version de la bibliothèque cliente. Vous vous assurez ainsi d'avoir sélectionné 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 qu'un utilisateur ait modifié 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 de 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'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 en renvoyant 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, rétablissez l'accès à la clé.