Determinazione di una misura realistica delle richieste al secondo per un server Web

15

Sto installando uno stack nginx e ottimizzando la configurazione prima di passare al live. Eseguendo ab per stress test della macchina, sono rimasto deluso nel vedere che le cose superano le 150 richieste al secondo con un numero significativo di richieste che impiegano> 1 secondo per tornare. Stranamente, la macchina stessa non stava nemmeno respirando affannosamente.

Alla fine ho pensato di pingare la scatola e ho visto tempi di ping intorno a 100-125 ms. (La macchina, con mia sorpresa, è in tutto il paese). Quindi, sembra che la latenza della rete stia dominando i miei test. Eseguendo gli stessi test da una macchina sulla stessa rete del server (tempi di ping <1 ms) e vedo> 5000 richieste al secondo, che è più in linea con quello che mi aspettavo dalla macchina.

Ma questo mi ha fatto pensare: come posso determinare e segnalare una misura "realistica" di richieste al secondo per un server web? Visualizzi sempre affermazioni sulle prestazioni, ma la latenza della rete non dovrebbe essere presa in considerazione? Sicuramente posso servire 5000 richieste al secondo a una macchina vicino al server, ma non a una macchina in tutto il paese. Se ho molte connessioni lente, alla fine avranno un impatto sulle prestazioni del mio server, giusto? O sto pensando a questo tutto sbagliato?

Perdonami se si tratta di roba di ingegneria di rete 101. Sono uno sviluppatore di professione.

Aggiornamento: modificato per chiarezza.

— don
fonte

abha un'opzione di concorrenza. A cosa l'hai impostato? Inoltre, se esegui il test da una connessione ADSL domestica, è probabile che il test sia dominato dalla larghezza di banda e non testerà nulla sul server.

— Ladadadada,

Ho familiarità con l'opzione di concorrenza di ab e ho provato una vasta gamma di valori per scoprire i limiti del riquadro. Come ho scritto sopra, capisco che i miei test iniziali erano dominati dalla rete e non riflettevano le capacità del server. Ma la mia domanda rimane valida: da dove la maggior parte delle persone esegue i test per ottenere metriche realistiche? I test eseguiti da un box sulla stessa rete del server (eliminando effettivamente qualsiasi latenza di rete dall'equazione) restituiscono grandi numeri, ma non sembrano numeri "giusti" poiché gli utenti reali arriveranno dall'esterno della rete.

— Don

I test eseguiti dalla stessa rete potrebbero infatti essere più "equi" in quanto essenzialmente ignorano la rete. I tuoi utenti sono probabilmente tutti su reti diverse, quindi la larghezza di banda aggregata di tutte quelle reti dovrebbe facilmente superare la larghezza di banda disponibile del tuo server. Considerando tutti gli utenti insieme, il collo di bottiglia è quindi la capacità del server - mentre considerando un singolo utente, il collo di bottiglia potrebbe essere la larghezza di banda di quel singolo utente. (Il test ideale, forse, verrebbe eseguito da più postazioni remote per simulare al meglio le circostanze reali, sebbene, nella maggior parte dei casi non dovrebbe essere necessario).

— cyberx86,

"Considerando tutti gli utenti insieme, il collo di bottiglia è quindi la capacità del server" - ha senso e sembra il modo giusto di pensarci. Suppongo che il server potrebbe trovarsi dietro un'apparecchiatura di rete scadente, limitando il suo tasso di risposta al mondo esterno, ma non è proprio il problema del server e deve essere affrontato separatamente. Qualcosa come Pingdom potrebbe essere usato per eseguire il test ideale, suppongo.

— Don

3

Se ti preoccupi delle prestazioni del tuo server quando accedi da qualche parte del mondo, chiedi a un amico da qualche parte nel mondo (dovrebbe avere una buona banda) per installare sproxy + siege sulla sua scatola di Linux. Basta scaricare, configurare, creare. Questi strumenti sono piccoli, si compilano in pochi secondi.

Prima di tutto, inizia sproxydalla scatola di Linux. Per impostazione predefinita, verrà eseguito sulla porta 9001 su localhost (127.0.0.1). Se si desidera accedervi dall'esterno, passare l'indirizzo IP in uscita come parametro.
Ora connettiti a sproxy impostando il tuo browser per utilizzare questo ip e porta come proxy per HTTP. Tutto ciò che fai da ora in poi viene registrato da sproxy e può essere riprodotto in seguito. Ora naviga sul tuo sito, fai ciò che i tuoi clienti farebbero e prova a fare cose "costose" che usano il tuo server.
Al termine, terminare lo sproxy premendo CTRL ^ C. Ha registrato le tue azioni su $HOME/urls.txt. Sposta il file dove risiede l'assedio. Per iniziare lo stress test, eseguire siege -f urls.txt -d NUM -c NUM. dindica il ritardo tra le richieste, quando si eseguono i test delle prestazioni, utilizzare 1 (secondo).cindica il numero di utenti simultanei simulati. Scegli a piacimento, ma inizia in basso. Siege ti mostrerà il numero di transazioni al secondo, errate, la durata media delle richieste ecc. È uno strumento potente e facile da usare.
Se avete bisogno di maggiori informazioni sui parametri (ce ne sono molti), controllare l' assedio manuale di un il manuale di sproxy

Per ottenere risultati più realistici, consenti a molte persone di testare il tuo server da vari paesi contemporaneamente e lascia che ti inviino le statistiche.

— SebiF
fonte

2

Le misure realistiche richieste / sec dovrebbero essere prese dai registri di accesso. IMO, la latenza della richiesta non ha nulla a che fare con il carico del server, poiché il server elabora tutte le richieste alla stessa velocità, indipendentemente dalla loro origine.

— ejaenv
fonte

1

Prendi in considerazione l'utilizzo di servizi come Soasta Cloudtest . Con esso puoi ottenere rapporti piuttosto dettagliati sui tuoi test ed eseguire test delle prestazioni da vari provider di cloud / virtualizzazione pubblici. Puoi configurare quanto duramente e per quanto tempo vuoi martellare i tuoi server. Hanno anche una versione " lite " gratuita in modo che tu possa vedere cosa può fare prima di impegnare denaro.

— Mxx
fonte