Questo scenario è uno stress test valido?

Question

Ho un'applicazione server che gestisce le richieste dei clienti in modo diverso.

Voglio sapere quanti utenti possono essere serviti con una latenza minima, quindi ho realizzato una piccola applicazione di stress test che simula le richieste degli utenti; allo stesso tempo, un'altra applicazione monitora l'utilizzo della memoria / CPU.

Lo strumento di stress test crea thread ogni secondo in cui ogni thread rappresenta un utente. Se lo stress test non può creare un nuovo thread a causa della mancanza di risorse, avvia una nuova istanza dello strumento di stress test.

Il problema è che ogni thread scrive nel file la latenza per ogni richiesta e il numero corrente di thread in esecuzione, quindi questo causa problemi di I / O poiché dopo un paio di minuti hai molti thread che devono scrivere anche sul disco questo comportamento non sarà presente nello scenario reale poiché il client richiede solo i dati.

Come posso superare questo problema poiché desidero misurare la latenza massima per utente?

PS:

Alcune risposte dicono di essere eseguite su macchine diverse per prendere in considerazione la latenza della rete ok, questo è il mio stress test finale attualmente sto facendo questo test sullo stesso server per scoprire quanti utenti sono supportati con una latenza minima.

Answer 1

Non è davvero chiaro se si tratti di un'applicazione di rete o meno. Se è in rete, puoi semplicemente ridimensionare lo stress test rubando il desktop di tutti nel fine settimana per eseguire lo stress test. Questo potrebbe essere il modo più semplice per ridimensionare il test se si tratta solo di alcuni test ad hoc.

Tuttavia, sembra che potrebbero esserci alcuni semplici miglioramenti. Se si intende che questo è uno stress test di lunga durata, invece di creare un nuovo thread per ogni richiesta, è possibile creare un pool di thread su cui lavorare (o ancora più semplice, utilizzare il pool di thread, che verrà ridimensionato automaticamente). Quindi definiresti un test per dire 2000 utenti e far girare 2000 thread che martellano il server. Ogni thread sarebbe essenzialmente in un ciclo che fa il test e si ripete.

Un altro elemento che non è chiaro è se tutti i thread stanno cercando di condividere un singolo file. Un modo per ridurre il collo di bottiglia sarebbe quello di mantenere le informazioni in memoria fino allo spegnimento del programma. Oppure crea un thread di scrittura, che è responsabile della scrittura del file e tutti gli altri thread gli forniscono informazioni. Se si esegue il backup di IO, il thread del writer verrà semplicemente tenuto in memoria fino a quando IO non sarà disponibile e nel frattempo i thread di lavoro potranno continuare a martellare il server. Tieni presente che, a causa della sincronizzazione del thread coinvolta, questo potrebbe non adattarsi correttamente, quindi potresti voler bufferizzare alcune voci nel thread di lavoro e sincronizzarlo con il thread del writer di file ogni 100 richieste. Non penso che questo costituirà un grosso problema poiché non sembra che stai monitorando qualcosa di più dei tempi di risposta.

Modifica: in base al commento Suggerirei di provare a utilizzare un singolo thread per gestire le operazioni IO in questo caso. Tutti i tuoi thread di lavoro invece di scrivere su un file, creare un oggetto con qualunque siano i dettagli e passarlo a una coda per essere scritto su un file. Per ridurre il blocco / sblocco, utilizzare anche una coda all'interno del thread di lavoro e sincronizzare solo ogni tanto. Assicurati di bloccare quando si scambiano le informazioni nel thread. Inoltre, forse guarderei l'utilizzo della memoria poiché ciò consentirà a qualsiasi cosa in sospeso di accumularsi in memoria. Se questo sta ancora causando il blocco di io, guarderei o scrivendo di meno, o forse sintonizzando o aggiungendo un disco rigido più veloce.

Answer 2

Se sei interessato alla latenza massima per utente, perché non raccoglierlo nel thread e quando interrompi il test chiedi a tutti i thread di scrivere la nostra latenza massima lì. Puoi anche fare statistiche, calcolando min / max / varianza e numero di thread / utenti in esecuzione. Non dovresti aggiornare neanche l'output dello schermo. se si teme la perdita di dati, scrivere i dati su disco frequentemente.

I thread non sono ottimali durante questo test per un'app client / server. Avendo solo un numero limitato di core, solo pochissimi thread funzionano davvero in parallelo, ma ottengono i loro tempi. È molto meglio, e ti dà anche alcuni dati sulla latenza della rete, per avviare il tuo programma su diversi client. Il software del server può - se è in grado di farlo - utilizzare il proprio hardware come nell'impostazione finale, dove i client verranno eseguiti in una LAN o WAN.

Ovviamente avrai un ambiente misto, dal momento che non puoi avere molti computer client simulati dagli utenti, ma scenari come le chiamate simultanee da hardware indipendente appariranno in una situazione di stress in quanto le chiamate non sono quasi serializzate attraverso il timelicing.