Questa pagina fornisce le best practice per il test di carico del servizio Cloud Run per determinare se viene scalato correttamente durante l'utilizzo in produzione e per individuare eventuali colli di bottiglia che ne impediscono la scalabilità.
Test da eseguire prima del test di carico
Identifica e risolvi i problemi di concorrenza in un ambiente di sviluppo o di test di piccole dimensioni prima di procedere con il test di carico. Misura la concorrenza dei container prima di eseguire un test di carico e assicurati che il tuo servizio Cloud Run venga avviato in modo affidabile.
Concentra i test dei contenitori su piccoli conteggi incrementali nelle esecuzioni scalate manualmente. Puoi approssimare lo scaling manuale in Cloud Run impostando maximum instances sul valore a cui vuoi scalare.
Se hai creato o modificato di recente l'immagine container, testala in modo indipendente prima di eseguire un test di carico.
Prima di eseguire un test di carico su larga scala, devi anche verificare altri tipi di problemi di prestazioni, come latenza e utilizzo della CPU eccessivi.
Utilizzare max instances in modo appropriato
Cloud Run applica un numero massimo di istanze per limitare lo scaling di un servizio. Il numero massimo predefinito di istanze è 100. Se prevedi che il test di carico superi questo valore predefinito, assicurati di collaborare con il tuo team dell'account Google e di impostare un nuovo valore massimo. Se non hai ancora un rapporto con un team dedicato all'account, contatta Google Cloud il team di vendita.
Il numero massimo di istanze che puoi selezionare dipende dai tuoi limiti di CPU e limiti di memoria, nonché dalla 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 europe-west1
La Google Cloud regione europe-west1 offre un limite di quota elevato, quindi Google consiglia di eseguire test di carico in europe-west1.
Coordina con il team dedicato al tuo account e invia una richiesta di assistenza con i dettagli di
ora e scala del test se prevedi di avvicinarti ai limiti di quota.
Testare 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 su Cloud Run e ne esegui il test di carico direttamente. Tuttavia, in alcuni casi, potresti non essere in grado di eseguire il deployment di una versione di test del tuo servizio. Ad esempio, il tuo servizio Cloud Run potrebbe far parte di un ecosistema complesso difficile da replicare in un ambiente di test.
In questi casi, puoi approssimare il rendimento del tuo servizio simulandolo con un servizio più semplice che abbia un utilizzo della CPU e tempi di inizializzazione comparabili.
Il tempo di inizializzazione è particolarmente importante per una scalabilità rapida. Tieni presente che
anche i test con qualcosa di troppo semplice sono problematici. Ad esempio, evita di eseguire test con un
semplice servizio hello world che restituisce le richieste ricevute senza alcuna elaborazione.
Utilizza un test harness per generare carichi
Puoi generare carichi di test che causano un picco controllato di traffico utilizzando un harness di test, ad esempio JMeter. Puoi utilizzare il numero di gruppi di thread JMeter e il ritardo tra le richieste nel test JMeter per aumentare il carico.
Puoi anche inviare semplici richieste HTTP o registrare una sessione del browser con JMeter. Cloud Run ti consente di testare il servizio senza accesso a internet utilizzando l'autenticazione sviluppatore. Ciò consente l'accesso da un banco di prova come JMeter, in esecuzione su una macchina virtuale Compute Engine collegata a un Virtual Private Cloud (VPC) associato al progetto.
Non generare carico da strumenti in cui la velocità e la concorrenza non possono essere controllate. Pub/Sub è una scelta di strumento scadente per generare carico perché non puoi controllare la velocità del traffico e il numero di client. Se non conosci la frequenza e la concorrenza, non saprai cosa stai testando.
Utilizzare l'analisi dettagliata dei log utilizzando i log esportati
Hai bisogno di un'analisi secondo per secondo degli eventi per comprendere la risposta del tuo servizio Cloud Run ai rapidi picchi di traffico. Per farlo è necessaria l'analisi dei log perché la granularità dei dati di monitoraggio non è sufficientemente dettagliata. L'analisi dei log ti consente anche di esaminare i motivi delle richieste con latenza elevata.
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 la destinazione BigQuery e un filtro di inclusione, ad esempio:
resource.type="cloud_run_revision"
resource.labels.service_name="[your app]"
Evitare avvii a freddo spuri
Per ridurre al minimo gli avvii a freddo riscontrati dagli utenti, imposta il numero minimo di istanze su almeno 1.
Assicurati che il servizio venga scalato in modo lineare
Ripeti il test con carichi diversi per assicurarti che il tuo servizio Cloud Run venga scalato in modo lineare con il carico e non raggiunga un collo di bottiglia limitante con un carico inferiore a quello previsto in produzione.
Analizzare e visualizzare i risultati in Colaboratory
Utilizza i grafici di monitoraggio del riepilogo per ottenere una comprensione generale dei risultati e integrare l'analisi dettagliata dei log utilizzando i log esportati.
I grafici di monitoraggio possono aiutarti a scoprire:
- Con quale rapidità, al secondo più vicino, vengono create e inizializzate le nuove istanze?
- Quanto sono distribuite uniformemente le richieste tra le diverse istanze?
- Con quale rapidità la latenza a diversi percentili può essere ridotta a un valore di stato stazionario?
Puoi utilizzare l'interfaccia utente della console per BigQuery per esaminare lo schema dei log esportati e visualizzare l'anteprima dei risultati. Google Cloud Esegui le query e traccia i risultati utilizzando Colab, che ha un'integrazione pronta con BigQuery, Pandas e Matplotlib. Colab si integra facilmente con strumenti di visualizzazione di dati avanzati come Seaborn.
Trovare i colli di bottiglia
I test di carico possono aiutarti a scoprire l'esistenza di codice inefficiente e colli di bottiglia di scalabilità. Il codice inefficiente comporta costi più elevati in quanto deve gestire più traffico, ma non impedisce necessariamente lo scaling. Ad esempio, una dipendenza da una traduzione del database con blocco a livello di tabella può essere un collo di bottiglia che impedirà lo scaling del servizio Cloud Run perché può essere eseguita una sola transazione alla volta.
Controllare il rendimento come percepito dal cliente
Puoi eseguire query sui log acquisiti da JMeter, in cui i log includono le latenze misurate sul client. Tuttavia, poiché gli strumenti di test del server come JMeter non sono uguali a un browser o a un client mobile, ti consigliamo di eseguire un test anche con un framework basato su browser, come Selenium Webdriver, o un framework di test client mobile. Fai attenzione alle latenze massime eccessive dovute all'inizializzazione della connessione TLS che potrebbe distorcere i risultati con valori anomali.
Riepilogo delle best practice
Esegui un test di carico per determinare se la migrazione a Cloud Run è la scelta giusta e se il tuo servizio può scalare fino al traffico massimo previsto. Esegui il test con un harness come JMeter. Esporta i log in BigQuery per un'analisi dettagliata.