Come includere test delle prestazioni degli utenti di 100k + su una pipeline CI

Hai (quasi) già detto la risposta:

a [not so] quick solution would include setting up an entire testing environment (outside Travis, of course), literally replicating the production environment, and using a dedicated system to spawn 100k separate processes, hitting the application running on the testing environment, and collecting reports.

Sì, questa è una buona soluzione. E, ancora meglio, ti costringerà ad automatizzare la configurazione di produzione . C'è un modo per farlo, non per usare un sistema "dedicato", invece di far ruotare e abbattere l'intero sistema in modo che funzioni solo quando ne hai bisogno.

Utilizza un servizio cloud come AWS per avviare un cluster di produzione in pochi secondi o minuti (e anche in grado di distruggerlo in pochi secondi o minuti) e quindi utilizzare un servizio cloud come AWS per far girare centinaia o migliaia di istanze per testare la tua app.

Questo è sicuramente possibile e costringerà te e il tuo team ad adottare un sacco di "buone pratiche". Non devi farlo in AWS, sono sicuro che anche Azure o Google Cloud funzionino perfettamente.

Dichiarazione di non responsabilità: ho partecipato a reinserimento di AWS alcuni anni fa e ho visto un intervento di un'azienda che ha fatto esattamente questo. Avevano degli script CloudFormation che potevano far girare un intero cluster di produzione (in un VPC non meno) in meno di dieci minuti, e poi usare migliaia di istanze spot per eseguire il martello sul cluster di produzione. Funzionava ogni giorno in pochi minuti e il costo era molto economico.

Poiché i test delle prestazioni dipendono quasi totalmente dall'ambiente di produzione o di implementazione, tali test nello sviluppo o nell'ambiente CI sono quasi privi di significato a meno che quell'ambiente non sia strettamente correlato all'ambiente finale inclusi eventuali carichi aggiuntivi o vincoli che il tuo ambiente di produzione ha.

Un esempio che ricordo era un sistema che, quando testato sull'ambiente di test, funzionava perfettamente ma sul reale impiego era inutilizzabile. L'ambiente di test aveva una connessione diretta, molto veloce, quindi la grafica grande e bella si presentava quasi all'istante, ma la maggior parte degli utenti utilizzava modem BAUD a 28k.

Anche il test richiederà molto tempo per essere eseguito, il che non è l'ideale in un ambiente CI.

Tuttavia, è possibile verificare che non sia vincolato a meno di 100k richieste individuando una richiesta di lunga durata o avendo una richiesta di modalità test speciale che non termina a meno che non sia segnalato a farlo e avendo un singolo client aperto 100k tale richiede ciascuno su una nuova connessione.

Credo che sia necessario eseguire il test delle prestazioni principali separatamente su base ad hoc poiché è molto più che il semplice controllo del tempo di risposta o della velocità effettiva. Quindi consiglierei di eseguire caricare test , Immergere test , test di stress , ecc. separatamente per scoprire qualsiasi bottlenecks , perdite di memoria , problemi di infrastruttura, ecc. e uno che scopri tutto e lo aggiusta e sarà contento di come funziona potresti creare un test ridimensionato per scopi di regressione .

1. Esegui il test di carico principale con 100k utenti virtuali
2. Identifica saturazione / punti di rottura, apporta correzioni alle prestazioni, ecc.
3. Esegui il test di carico ridimensionato con utenti virtuali 1k per ottenere le metriche delle prestazioni di base
4. Aggiungi questo test di carico ridimensionato con utenti virtuali da 1k da eseguire su ogni build a fini di regressione, quindi se nuove funzionalità o correzioni di bug causeranno un peggioramento delle prestazioni, riceverai una notifica.

Vedi Esecuzione di un test JMeter tramite Jenkins Pipeline - Un tutorial per esempio di configurazione.

I test delle prestazioni dovrebbero essere eseguiti su hardware che sia al pari del tuo ambiente di produzione. Altrimenti non puoi stabilire se i tuoi risultati corrisponderanno a ciò che vedranno i tuoi veri utenti.

Detto questo, ci sono alcune cose che puoi fare per stimare stabilendo una linea di base.

1. Esegui un ciclo completo di test sul tuo ambiente di preproduzione / test delle prestazioni e porta il sistema a un punto in cui soddisfa i tuoi SLA.

2. Esegui lo stesso ciclo nell'ambiente CI o su una macchina virtuale. Assicurati di utilizzare un codice identico. Ovviamente funzionerà a un livello molto più basso di prestazioni.

3. Poiché sai che i risultati dalla # 1 sono accettabili e che i # 1 e # 2 eseguono il codice identico, puoi utilizzare i risultati della # 2 come base di riferimento.

4. Continua a eseguire test delle prestazioni nell'ambiente CI e genera un avviso se le prestazioni peggiorano rispetto alla linea di base stabilita nel passaggio 2.

Naturalmente, le prestazioni non si ridimensionano allo stesso modo su una VM come nella tua web farm di produzione multi-nodo, quindi dobbiamo fare un sacco di presupposti per abbracciare questi risultati. Se ottiene un rallentamento del 10% nell'ambiente CI, potrebbe non corrispondere a una perdita del 10% nella produzione, potrebbe essere inferiore o potrebbe essere superiore. Anche se rimane invariato, non è detto che le prestazioni non siano influenzate in alcun modo, perché forse l'ambiente CI è diversamente sensibile a variabili diverse. Nondimeno, è meglio di niente.