Questa pagina fornisce le best practice per i test di carico Servizio Cloud Run per determinare se scala correttamente durante all'uso in produzione e per individuare eventuali colli di bottiglia che ne impediscono la scalabilità.
Test da eseguire prima dei test di carico
Identificare e risolvere i problemi di contemporaneità in uno sviluppo o in un piccolo test dell'ambiente di rete prima di procedere con il test di carico. Misura la contemporaneità dei container prima di eseguire un test di carico e assicurati che Cloud Run che il servizio si avvii in modo affidabile.
Incentra i test dei container su piccoli conteggi incrementali nelle esecuzioni scalate manualmente. Puoi approssimare la scalabilità manuale in Cloud Run impostando numero massimo di istanze al valore che vuoi scalare.
Se hai creato l'immagine container solo di recente o se hai modificato di recente il valore dell'immagine container, testala in modo indipendente prima di eseguire un test di carico.
Dovresti anche controllare altri tipi di problemi di prestazioni, come di latenza e utilizzo della CPU prima di eseguire un test di carico su larga scala.
Usa max instances in modo appropriato
Cloud Run applica un numero massimo di istanze per limitare la scalabilità di un servizio. Il numero massimo predefinito di istanze è 100. Se prevedi che il test di carico superi questo valore predefinito, assicurati di utilizzare i tuoi team dedicato all'account di Google e impostare un nuovo valore massimo. Se non hai ancora una relazione con un team dedicato all'account, contatta il team di vendita Google Cloud.
Il numero massimo di istanze che puoi selezionare dipende Limiti di CPU e limiti di memoria e la regione in cui esegui il deployment.
Questi limiti sono gestiti da un limite di quota e possono essere aumentati effettuando una richiesta di aumento del limite di quota.
Test di carico nella regione us-central1
La regione Google Cloud us-central1 offre un limite di quota elevato, perciò Google
consiglia i test di carico in us-central1. Coordinati con il team dedicato all'account
e invia una richiesta di assistenza con i dettagli delle tempistiche e della scala del test
se prevedi di avvicinarti ai limiti di quota.
Testa un profilo di utilizzo della CPU e di inizializzazione del servizio appropriato
In uno scenario ideale, esegui il deployment di una versione di test del tuo servizio in Cloud Run per testarlo direttamente. Tuttavia, in alcuni casi, è possibile non potrai eseguire il deployment di una versione di test del tuo servizio. Ad esempio, Il servizio Cloud Run potrebbe far parte di un ecosistema complesso e difficile da replicare in un ambiente di test.
In questi casi, puoi simulare le prestazioni del tuo servizio
con un servizio più semplice che offre
un utilizzo della CPU e tempi di inizializzazione paragonabili.
Il tempo di inizializzazione è particolarmente importante per una scalabilità rapida. Tieni presente che
fare test con qualcosa di troppo semplice è anch'esso problematico. Ad esempio, evita di eseguire il test con un
semplice servizio hello world che restituisce le richieste ricevute senza alcuna elaborazione.
Utilizza un cablaggio di test per generare carichi
Puoi generare carichi di prova generando un picco controllato di traffico utilizzando un modello di sistema come JMeter. Puoi usare il numero di thread JMeter gruppi di dati e ritardo tra le richieste nel test JMeter per aumentare il carico.
Puoi anche inviare semplici richieste HTTP o registrare una sessione del browser JMeter. Cloud Run consente di testare il servizio senza accesso a internet mediante l'autenticazione degli sviluppatori. Questo permette l'accesso da un cablaggio di test come JMeter, in esecuzione su un Compute Engine macchina virtuale collegata a un Virtual Private Cloud associato al progetto.
Non generare carico da strumenti in cui non è possibile controllare velocità e contemporaneità. Pub/Sub è una scelta sbagliata di strumento per generare carico perché non puoi controllare della velocità del traffico e del numero di clienti. Se non conosci la velocità e la contemporaneità, non saprai cosa stai testando.
Utilizza l'analisi dettagliata dei log mediante i log esportati
È necessaria un'analisi secondo per secondo degli eventi per comprendere il funzionamento di Cloud Run del servizio a rapidi picchi di traffico. A questo scopo è necessaria l'analisi dei log perché la granularità dei dati di monitoraggio non è sufficientemente e granulare. L'analisi dei log consente inoltre di esaminare i motivi delle richieste con una latenza di pochi millisecondi.
Quando scrivi i log, puoi ottenere prestazioni di logging migliori scrivendo direttamente
in stdout anziché utilizzare una libreria client di Cloud Logging.
Per configurare un'esportazione dei log prima di iniziare il test, crea un sink di log con BigQuery di destinazione e un filtro di inclusione, come:
resource.type="cloud_run_revision"
resource.labels.service_name="[your app]"
Evitare avvii a freddo spurie
Per ridurre al minimo gli avvii a freddo utilizzate dagli utenti, imposta il numero minimo di istanze ad almeno 1.
Assicurati che il servizio esegua lo scale out in modo lineare
Ripeti il test con carichi diversi per assicurarti che il tuo servizio Cloud Run fa lo scale out in modo lineare con il carico e non raggiunge un collo di bottiglia limitante in corrispondenza di un è inferiore a quanto ci si aspetti in produzione.
Analizza e visualizza i risultati in Colab
Utilizza i grafici di monitoraggio di riepilogo per una comprensione generale dei risultati per integrare l'analisi dettagliata dei log utilizzando i log esportati.
I grafici di monitoraggio possono aiutarti a scoprire:
- Quanto rapidamente vengono create e inizializzate le nuove istanze, al secondo più vicino?
- Quanto sono uniformi le richieste distribuite tra le diverse istanze?
- Quanto rapidamente è possibile trascinare la latenza a percentili diversi fino a un valore stabile?
Puoi usare l'interfaccia utente della console Google Cloud per fare in modo che BigQuery lo schema dei log esportato e i risultati in anteprima. Esegui le query e traccia i risultati utilizzando Colab, che è pronto integrazione con BigQuery, Pandas e Matplotlab. Colab integra anche facilmente grazie a strumenti di visualizzazione dei dati dettagliati come Seaborn.
Individua i colli di bottiglia
I test di carico possono aiutarti a scoprire l'esistenza di codice e scalabilità inefficienti colli di bottiglia. Un codice inefficiente comporta costi più alti in quanto deve gestire più ma non impedisce necessariamente la scalabilità. Ad esempio, una dipendenza la traduzione del database con il blocco a livello di tabella può essere un collo di bottiglia impedisce la scalabilità del servizio Cloud Run perché solo una transazione possono essere eseguiti contemporaneamente.
Controlla il rendimento in base alle esperienze del cliente
Puoi eseguire query sui log acquisiti da JMeter, dove i log includono le latenze misurate sul client. Tuttavia, poiché gli strumenti di test del server come JMeter non corrispondono a un browser o a un client mobile, ti consigliamo inoltre di eseguire un test un framework basato su browser, Selenium Webdriver o dispositivo mobile di test del cliente. Fai attenzione alle latenze massime eccessive dovute all'inizializzazione della connessione TLS che potrebbe distorcere i risultati con outlier.
Riepilogo delle best practice
Esegui un test di carico per determinare se la migrazione a Cloud Run è la scelta giusta e che il servizio sia scalabile al massimo traffico previsto. Esegui il test con un imbracatura come JMeter. Esporta i log in BigQuery per un'analisi dettagliata.