Tipi di test di carico

I seguenti tipi di test si basano sulle domande di base elencate in precedenza nella guida.

Quanto carico può sopportare la mia applicazione?

Quando imposti un test per determinare il carico che l'applicazione è in grado di sopportare, devi innanzitutto decidere se misurarlo in richieste al secondo (req/s), tempo di risposta (secondi) o in utenti simultanei. In entrambi i casi, devi definire quale parte dell'applicazione viene testata.

• La navigazione nel sito è un carico che si ottiene visitando più pagine o endpoint o richiedendo dati da un singolo endpoint utilizzando parametri diversi per ogni richiesta. Spesso è possibile ottenere questo risultato utilizzando gli strumenti di base descritti nella sezione Strumenti da utilizzare. Poiché la cache è spesso un componente fondamentale di un'applicazione, devi stabilire se includere un livello di cache nel test.

• Il test dei flussi di lavoro transazionali, ad esempio un checkout in cui le richieste dipendono l'una dall'altra e trasferiscono i dati tra le richieste, richiede strumenti più complessi. Inoltre, poiché la misura delle richieste ha una rilevanza limitata nel contesto di una transazione in più fasi, è più preciso contare l'intera transazione, che deve essere emessa come datapoint separato dallo strumento. Gli strumenti Apache JMeter e k6 possono essere configurati per fornire questi punti dati.

Definisci la soglia accettabile per le prestazioni e il tasso di errore del sistema di destinazione. Per alcuni sistemi, i tempi di risposta potrebbero non interessarti se l'evento viene elaborato correttamente. Per molte applicazioni, come quelle che prevedono l'interazione con l'utente, definisci i limiti di ciò che è accettabile per l'utente finale.

Spesso è utile eseguire i test per fasi. Il carico aumenta ad ogni fase fino a raggiungere la soglia definita. Per i test ripetuti, è possibile imparare dai test precedenti e migliorare la procedura per eseguire meno fasi in un test e ottenere comunque risultati validi.

La mia applicazione è in grado di gestire il carico X?

Analogamente al test precedente, il carico in questo test può essere definito come richieste/s o come utenti simultanei, a seconda della natura dell'applicazione che si sta testando. Questo test è una versione semplificata del precedente. Qui, deve essere inviato un carico di lavoro specifico e il sistema dovrebbe essere in grado di gestirlo. È importante scegliere uno strumento di test che supporti la definizione del volume di carico richiesto.

Anche il tempo necessario per eseguire il test può essere importante. Alcuni effetti possono essere osservati solo quando un test viene eseguito per un periodo di tempo più lungo. Ad esempio, la contropressione può causare il sovraccarico delle code. Se si desidera replicare un sistema di produzione e trarre conclusioni valide, il tempo necessario per eseguire il test può influire sul dimensionamento del sistema di test.

La mia applicazione si dimensiona automaticamente verso l'alto e verso il basso?

L'elasticità è un punto di forza fondamentale del cloud ed è una fonte chiave di riduzione dei costi. Verificare se l'applicazione può essere dimensionata correttamente, in modo da poter beneficiare con sicurezza dell'elasticità, dovrebbe far parte del tuo percorso verso il cloud.

È necessario identificare le metriche chiave utilizzate per il dimensionamento verso l'alto e verso il basso. In genere, si tratta del carico della CPU dei sistemi di destinazione. Un endpoint che crea il carico della CPU può essere utilizzato come destinazione.

Poiché questo test non richiede la rappresentabilità, si può beneficiare di un endpoint privo di effetti collaterali. Inoltre, è preferibile non avviare un flusso che permetta la persistenza dei dati che potrebbero accumularsi o che avvii processi successivi generando costi inutili o bloccando il carico.

Esegui il test in un processo a fasi, aumentando gradualmente il carico. Gli intervalli devono essere sufficientemente lunghi in modo che, in ogni fase, le metriche siano in grado di avviare il dimensionamento. Ad esempio, se di norma il carico della CPU deve essere superiore al 70% per un periodo di 5 minuti, i passaggi devono essere più lunghi di 5 minuti per consentire l'avvio e l'esecuzione dell'evento di dimensionamento. Puoi inoltre verificare che il dimensionamento funzioni correttamente e che sia stata corretta la situazione di carico creata.

Valuta la possibilità di iniziare il test di dimensionamento con più di un server. In un ambiente di piccole dimensioni, il dimensionamento può essere lento e richiedere più cicli per far fronte al carico. E un cluster EC2 Auto Scaling può solo raddoppiare le sue dimensioni. Ciò significa che se si inizia con un server e si avvia il test di carico, il primo evento di dimensionamento massimo può essere costituito solo da due server. Se il carico generato richiedesse tre server, sarebbero necessari due eventi di dimensionamento, che potrebbero richiedere 20 minuti o più.

Controlla il trigger desiderato per l'evento di dimensionamento verso l'alto e verifica se il dimensionamento è appropriato per il carico effettivo.

Se hai implementato un evento di dimensionamento verso il basso, puoi anche testarlo in modo graduale. Controlla se il dimensionamento verso il basso è applicabile e appropriato per il carico esistente e verifica che non venga avviato nuovamente un dimensionamento verso l'alto immediato.

Il comportamento della mia applicazione peggiora nel tempo con un carico elevato costante?

Alcuni effetti possono essere osservati solo quando il carico viene generato per un periodo di tempo prolungato. Uno degli effetti più importanti è la contropressione. Ciò significa che quando un sistema è troppo lento per elaborare il numero di richieste alla velocità con cui arrivano, le prestazioni dei sistemi client peggiorano.

Questo fenomeno è più facile da osservare se il sistema lento è l'obiettivo del carico. In una configurazione più complessa, è possibile osservare l'effetto solo quando l'impatto del test di carico si propaga. Una soluzione di tracciamento in grado di visualizzare i tempi di risposta tra ciascuno dei servizi in un sistema distribuito non solo mostra i risultati più velocemente, ma può aiutare a identificare il sistema che funge da collo di bottiglia. È possibile identificare il sistema a collo di bottiglia ottenendo l'ID di correlazione dei messaggi dai file di log. Ogni richiesta mantiene lo stesso ID su tutti i sistemi sottoposti al test di carico.

L'utilizzo di un ID di correlazione consente di tracciare l'intero percorso di un singolo messaggio attraverso tutti i diversi componenti della piattaforma. Con queste informazioni, puoi calcolare il tempo di elaborazione per ogni singolo componente attraversato dal tuo messaggio (processing_time = departure_time - arrival_time) e identificare quello più lento. Zipkin, Jaeger e AWS X-Ray sono soluzioni importanti in questo settore.

Per risultati più affidabili, scegli uno strumento che supporti l'impostazione di una frequenza di richiesta costante. Ciò significa che se il sistema di destinazione diventa più lento, la concomitanza dello strumento di test deve aumentare per mantenere costante il numero di richieste al secondo. Quando il sistema inizia a rispondere più lentamente, blocca più thread e riduce la frequenza di richiesta dello strumento di generazione del carico. Uno strumento con una frequenza di richieste costante deve aumentare la concomitanza quando accade e si verificheranno errori più rapidamente. Invece di essere misurato in base alle richieste al secondo raggiunte, il peggioramento verrà misurato in base alla latenza e persino alle richieste non riuscite.

La mia applicazione funziona?

Di solito, non si crea un carico elevato, ma piuttosto un numero ragionevole di richieste che verificano la funzionalità. È inoltre possibile eseguire questa operazione periodicamente durante la fase di produzione, quando i clienti non visitano i flussi testati, per disporre di un ulteriore livello di monitoraggio.

Come scorciatoia, gli scenari già creati per i test di carico possono essere riutilizzati in produzione con un carico inferiore configurato.