Questa pagina fornisce le best practice per i test di carico del servizio Cloud Run per determinare se esegue il ridimensionamento correttamente durante l'utilizzo in produzione e per trovare eventuali colli di bottiglia che ne impediscono il ridimensionamento.
Test da eseguire prima dei 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 i 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 o modificato di recente l'immagine container, testala indipendentemente 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 il ridimensionamento di un servizio. Il numero massimo di istanze predefinito è 100. Se prevedi che il test di carico superi questo valore predefinito, assicurati di collaborare con il team dell'account di Google e di impostare un nuovo valore massimo. Se non hai ancora un rapporto con un team dedicato all'account, contatta il team di vendita di Google Cloud.
Il numero massimo di istanze che puoi selezionare dipende dai limiti di CPU e dai 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 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 servizio su Cloud Run e ne esegui direttamente il test di carico. Tuttavia, in alcuni casi, è possibile non potrai 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 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 la scalabilità rapida. Tieni presente che anche eseguire test con qualcosa di troppo semplice è problematico. Ad esempio, evita di eseguire il test con un
semplice servizio hello world che restituisce le richieste ricevute senza alcuna elaborazione.
Utilizzare un test harness per generare carichi
Puoi generare carichi di test che causano un picco controllato del traffico utilizzando un test harness, come 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 tuo servizio senza accesso a internet utilizzando l'autenticazione dello sviluppatore. In questo modo, è possibile accedere da un framework di test come JMeter, in esecuzione su una macchina virtuale Compute Engine collegata a un Virtual Private Cloud associato al progetto.
Non generare carica da strumenti in cui non è possibile controllare la frequenza e la concorrenza. Pub/Sub non è uno strumento adatto per generare carico, perché non è possibile controllare della velocità del traffico e del numero di clienti. Se non conosci la frequenza e la concorrenza, non saprai cosa stai testando.
Utilizzare l'analisi dettagliata dei log utilizzando 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 servizio Cloud Run sia scalabile in modo lineare con il carico e non raggiunga un collo di bottiglia limitante con un carico inferiore a quello previsto in produzione.
Analizza e visualizza i risultati in Colab
Utilizza i grafici di monitoraggio di riepilogo per ottenere una panoramica dei risultati e integrare l'analisi dettagliata dei log utilizzando i log esportati.
I grafici di monitoraggio possono aiutarti a scoprire:
- Con quale rapidità, arrotondato al secondo più vicino, vengono create e inizializzate le nuove istanze?
- Le richieste sono distribuite in modo uniforme tra le diverse istanze?
- Quanto velocemente la latenza in diversi percentile può essere ridotta a un valore di stato stazionario?
Puoi utilizzare l'interfaccia utente della console Google Cloud in modo che BigQuery lo schema del 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 si integra anche facilemente con strumenti di visualizzazione dei dati avanzati come Seaborn.
Individua i colli di bottiglia
I test di carico possono aiutarti a scoprire l'esistenza di codice inefficiente e di colli di bottiglia di scalabilità. 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 impediscono la scalabilità del servizio Cloud Run perché solo una transazione possono essere eseguiti contemporaneamente.
Controllare il rendimento percepito dal 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 se il tuo servizio può scalare in base al traffico massimo previsto. Esegui il test con un harness come JMeter. Esportare i log in BigQuery per un'analisi dettagliata.