Come interpretare i risultati del banco di assedio o di Apache

Question

Abbiamo un sito basato su MySQL che occasionalmente ottengono 100.000 utenti nello spazio di 48 ore, tutti che accedono al sito e fanno acquisti.

Stiamo tentando di simulare questo tipo di carico utilizzando strumenti come Apache Bench e Siege.

Mentre la metrica chiave mi sembra il numero di utenti simultanei, e abbiamo i risultati del nostro rapporto, ci sentiamo ancora come se fossimo al buio.

Quello che voglio chiedere è: che tipo di cose dovremmo provare per anticipare questo tipo di traffico?

50 utenti contemporanei 1000 volte? 500 utenti concomitanti 10 volte?

Stiamo esaminando errori DB, timeout di apache e tempi di risposta. Cos'altro dovremmo guardare?

Questa è una domanda vaga e so che non esiste una risposta "giusta", stiamo solo cercando alcune considerazioni generali su come determinare realisticamente ciò che la nostra infrastruttura può gestire.

Grazie in anticipo!

Answer 1

Idealmente si desidera modellare il proprio utilizzo per l'utente, ma la creazione di sessioni simultanee simulate per utenti 100k non è in genere facilmente realizzabile. La migliore fonte sarebbe quella di controllare i registri per l'ora più impegnativa e cercare di capire un modo per modellare quel livello di carico.

Il database è in genere una parte fondamentale dell'infrastruttura, quindi vorrei prendere in considerazione la registrazione del numero e della lunghezza delle attese di blocco nonché il numero e la durata delle istruzioni db.

Un altro elemento chiave da osservare è la lunghezza della coda del disco.

Principalmente il processo consiste nel cercare risposte lente in tutto il sito o per pagine specifiche e quindi perfezionare la causa.

Il problema più grande per il test di carico è che è piuttosto difficile testare la rete e se si dispone (come la maggior parte dei siti pubblici) di una larghezza di banda limitata attraverso il proprio ISP, ciò potrebbe creare un problema di prestazioni che non si riflette nel carico test.

Answer 2

Gli utenti simultanei sono sicuramente uno dei fattori chiave, in particolare per quanto riguarda i pool di connessioni DB, ecc. Ma è anche necessario verificare che la velocità di pagina (pagine/sec) dei test sia compresa nell'intervallo. aspettarsi. Se il tempo di attesa nei tuoi test è troppo alto, puoi simulare accidentalmente una velocità di pagina molto più alta (o più bassa) rispetto al tuo traffico reale. Il tempo di riflessione è la quantità di tempo che l'utente spende tra le richieste di pagina: lettura della pagina, compilazione di un modulo, ecc.

A seconda delle altre informazioni a disposizione, questo potrebbe aiutare a calcolare il numero di utenti simultanei a simulate: Virtual User Calculators

Il tempo di caricamento completo della pagina visualizzato dall'utente finale è solitamente la metrica più importante per valutare le prestazioni del sistema. Dovrai anche cercare i tassi di fallimento su tutte le transazioni. Dovresti anche essere alla ricerca di transazioni che non si completano mai. Alcuni strumenti di test non riportano questi risultati molto bene, consentendo agli utenti simulati di rimanere bloccati indefinitamente quando il server non risponde ... e non riportando questa condizione. Cerca strumenti che riportino il numero di utenti in attesa su una determinata pagina o transazione e il tempo medio che gli utenti stanno aspettando.

Per quanto riguarda le metriche lato server da cercare, su quali altre tecnologie è basata la vostra app? Ti consigliamo di guardare cose diverse per un'app .NET rispetto a un'app PHP.

Infine, abbiamo trovato molto prezioso esaminare il modo in cui il sistema risponde all'aumento del carico, piuttosto che considerare solo un singolo livello di carico. This article entra più nel dettaglio.