Questo documento fornisce alcuni suggerimenti comuni per la risoluzione dei problemi durante la pubblicazione di messaggi in un argomento Pub/Sub standard.
Scopri di più su come pubblicare messaggi negli argomenti e sulle diverse funzionalità.
Latenza di pubblicazione elevata
La latenza di pubblicazione è il tempo necessario per completare una richiesta di pubblicazione emessa da un client di un publisher. La latenza di pubblicazione è distinta dalla latenza di consegna end-to-end, ovvero il tempo necessario affinché un messaggio pubblicato in Pub/Sub venga consegnato a un client di un sottoscrittore. Potresti osservare un'elevata latenza di pubblicazione o una latenza end-to-end anche quando il valore dell'altro tipo di latenza è basso. È possibile che si verifichi un'elevata latenza di pubblicazione a livello del client del publisher Pub/Sub, in transito tra il client e il backend di Pub/Sub o nel backend di Pub/Sub. Puoi controllare la latenza di pubblicazione sostenuta nel backend Pub/Sub utilizzando la metrica topic/send_request_latencies. Un'elevata latenza di pubblicazione nel backend potrebbe essere dovuta ai seguenti fattori:
Pub/Sub è progettato per una distribuzione a bassa latenza e ad alta velocità effettiva. Se l'argomento ha una velocità effettiva bassa, l'inizializzazione delle risorse associate all'argomento potrebbe richiedere più tempo.
L'utilizzo di un criterio di archiviazione dei messaggi potrebbe influire sulla latenza complessiva delle richieste all'argomento e alla sottoscrizione. Controlla le implicazioni relative a prestazioni e disponibilità associate all'utilizzo di questa configurazione.
Se il tuo client publisher nota una latenza di pubblicazione notevolmente superiore a quella indicata nella metrica, ciò potrebbe essere un segnale di uno di questi fattori lato client:
Assicurati di non creare un nuovo editore per ogni pubblicazione. Per pubblicare tutti i messaggi, ti consigliamo di utilizzare un unico client publisher per argomento per applicazione. L'avvio di nuovi oggetti publisher e l'aggiunta di nuovi thread ha un costo di latenza. Se utilizzi Cloud Functions per pubblicare messaggi, tieni presente che le chiamate possono influire anche sulla latenza di pubblicazione.
Se ritieni che le impostazioni predefinite per i nuovi tentativi non siano sufficienti per il tuo caso d'uso, apporta le modifiche necessarie. Tuttavia, verifica che i nuovi valori non siano troppo alti. Scopri come configurare l'opzione Riprova richieste.
Tieni presente che un'elevata latenza di pubblicazione può causare DEADLINE_EXCEEDED errori, di cui parleremo nella prossima sezione.
Le operazioni di pubblicazione non riescono con DEADLINE_EXCEEDED
Un errore DEADLINE_EXCEEDED durante una richiesta di pubblicazione indica che non è stato possibile completare la richiesta entro il tempo stabilito. Ciò potrebbe essere dovuto a vari fattori, come la mancata ricezione delle richieste al servizio Pub/Sub o problemi di prestazioni che interessano le richieste.
Per verificare che le richieste di pubblicazione raggiungano il servizio Pub/Sub, monitora l'argomento utilizzando la metrica topic/send_request_count, raggruppate per response_code. Questa metrica consente di determinare se le richieste non vanno a buon fine prima di raggiungere l'argomento Pub/Sub. Se la metrica è vuota, esiste un fattore esterno che impedisce ai messaggi di raggiungere il servizio Pub/Sub. Inoltre, per escludere la possibilità che si verifichino problemi intermittenti, controlla la percentuale di errori. Se la percentuale di errore è molto bassa, potrebbe trattarsi di un problema intermittente.
Se le richieste raggiungono Pub/Sub, ecco alcune possibili cause dell'errore DEADLINE_EXCEEDED delle operazioni di pubblicazione:
Collo di bottiglia lato client
Gli errori di pubblicazione sono probabilmente causati da un collo di bottiglia lato client, ad esempio memoria insufficiente, pressione della CPU, integrità del thread errata o congestione della rete nella VM che ospita il client del publisher. Se una chiamata Publish restituisce DEADLINE_EXCEEDED, è possibile che le chiamate Publish asincrone vengano accodati più rapidamente di quanto non siano inviate al servizio, il che aumenta progressivamente la latenza della richiesta. Inoltre, verifica se una delle seguenti condizioni può aiutare a determinare un possibile collo di bottiglia nel tuo sistema:
Verifica se i messaggi vengono pubblicati più velocemente di quanto il client possa inviarli. Di solito, ogni chiamata
Publishasincrona restituisce un oggettoFuture. Per monitorare il numero di messaggi in attesa di invio, memorizza il numero di messaggi da inviare con ogni chiamata aPublished eliminalo solo nel callback dell'oggettoFuture.Assicurati di disporre di una larghezza di banda in caricamento sufficiente tra la macchina su cui è in esecuzione il publisher e Google Cloud. Le reti Wi-Fi di sviluppo hanno tipicamente una larghezza di banda compresa tra 1 e 10 MB/s, o 1000-10.000 messaggi tipici al secondo. La pubblicazione dei messaggi in un loop senza alcuna limitazione di frequenza potrebbe creare un breve burst di larghezza di banda elevata in un breve periodo di tempo. Per evitare che ciò accada, puoi eseguire il publisher su una macchina all'interno di Google Cloud o ridurre la frequenza di pubblicazione dei messaggi in modo che corrispondano alla larghezza di banda disponibile.
Controlla se noti una latenza molto elevata tra il tuo host e Google Cloud per qualsiasi motivo, come la congestione della rete di avvio o l'applicazione di firewall. Il calcolo della velocità effettiva di rete consente di individuare la larghezza di banda e la latenza in base a scenari diversi.
Essenzialmente, ci sono dei limiti alla quantità di dati che una singola macchina può pubblicare. Potrebbe essere necessario provare a scalare orizzontalmente o eseguire più istanze del client del publisher su più computer. Testare i client Cloud Pub/Sub per massimizzare le prestazioni dei flussi di dati dimostra come Pub/Sub scala su una singola VM Google Cloud con un numero crescente di CPU. Ad esempio, puoi raggiungere da 500 MB/s a 700 MB/s per messaggi da 1 KB su un'istanza Compute Engine a 16 core.
Durata del timeout di pubblicazione non adeguata
Per ridurre il tasso di timeout per le chiamate di pubblicazione, assicurati di disporre di un timeout sufficientemente lungo definito nelle impostazioni per i nuovi tentativi del client del publisher. Per le impostazioni relative ai nuovi tentativi, imposta la scadenza iniziale su 10 secondi e il timeout totale su 600 secondi. Anche se non stai accumulando un grande backlog di messaggi non inviati, picchi occasionali nella latenza delle richieste possono causare il timeout delle chiamate di pubblicazione. Tuttavia, se i problemi sono causati da un collo di bottiglia persistente anziché da timeout occasionali, un numero maggiore di tentativi potrebbe determinare un numero maggiore di errori.
Problemi relativi alla libreria client
È possibile che sia in esecuzione una versione della libreria client che presenta un problema noto. Il seguente elenco include i tracker dei problemi per tutte le librerie client. Se rilevi un problema noto che interessa la versione della libreria client in uso, esegui l'upgrade alla versione più recente della libreria client. In questo modo, avrai la certezza di aver ricevuto tutti gli aggiornamenti pertinenti, tra cui correzioni e miglioramenti delle prestazioni.
C++
C#
Go
Java
Node.js
PHP
Python
Ruby
Problemi relativi allo schema
Se le tue pubblicazioni iniziano a restituire INVALID_ARGUMENT, è possibile che qualcuno abbia aggiornato l'argomento per modificare lo schema associato, eliminato lo schema o eliminato le revisioni dello schema associate all'argomento. In questo caso, aggiorna le impostazioni dello schema dell'argomento in base a uno schema e a un insieme di revisioni corrispondenti ai messaggi da pubblicare oppure modifica il formato del messaggio in modo che corrisponda allo schema corrente.
Problemi di crittografia dei messaggi
Se hai configurato l'argomento Pub/Sub per criptare i messaggi pubblicati utilizzando una chiave di crittografia gestita dal cliente, la pubblicazione potrebbe non riuscire e generare un errore FAILED_PRECONDITION. Questo errore può verificarsi se la chiave Cloud KMS è disabilitata o se le chiavi gestite esternamente tramite Cloud EKM non sono più accessibili. Per riprendere la pubblicazione, ripristina l'accesso alla chiave.