2010-03-27 10 views
7

Sto pianificando di configurare nginx come proxy inverso. Avrò l'apache per consegnare il mio contenuto dinamico, e nginx fornirà il contenuto statico.Come eseguire il benchmark della configurazione di apache/nginx

La mia configurazione che ho ora è solo Apache con fastCGI. Questo non mi dà problemi di configurazione e funziona alla grande.

Dopo aver impostato nginx, desidero eseguire alcuni benchmark per vedere se ho effettivamente ottenuto alcuni aumenti delle prestazioni, altrimenti tornerò indietro.

Qualcuno sa come posso eseguire il benchmark su questo tipo di configurazione? O forse qualcuno lo ha già fatto e ha dei risultati in scatola, sarò lieto di ascoltarli.

PS.So che questo è più un tipo serverfault di domanda, ma ho visto numerosi post su apache e nginx così ho pensato di fare un tentativo

risposta

15

migliore soluzione? Siege.

più accurato strumento di benchmarking di ab

+1

benvenuto in SO. e lo controllerò. –

7

una sola parola: ab

+0

Grazie per la risposta semplice. Non ho mai saputo che l'apache abbia un tale strumento. Questo strumento fornirà solo i risultati del benchmark per Apache. O anche questo rifletterà le modifiche di nginx apportate alla configurazione. –

+1

fa solo query http, è un modo semplice per confrontare qualsiasi server http. – Javier

+2

ab -k -n 10000 -c 50 http: // url.to/test Questo può testare il front end/le pagine statiche oi passthrough ad apache per il contenuto dinamico. Un'altra possibilità è http://www.acme.com/software/http_load/ che consente di specificare un elenco di URL da testare. ab è un punto di riferimento di utilità alquanto limitata, ma puoi almeno ricavarne alcune idee generali. –

6

Un paio di cose:

  1. Non utilizzare ab. È single-threaded e probabilmente finirai con il benchmarking piuttosto che con il tuo server HTTP.

  2. Non eseguire qualsiasi strumento di sollecitazione che si utilizza sullo stesso sistema del server. Il server HTTP sarà in competizione con lo strumento per CPU e altre risorse. La versione idealizzata di una rete di localhost Plus non indica l'intera immagine (vedi punto 4).

  3. Prestare attenzione alla memoria e all'utilizzo della CPU durante i test. Così tante persone non considerano mai questo fattore. Anche se entrambe le configurazioni hanno prestazioni uguali, se si utilizza una frazione della RAM/CPU, allora si ha un vincitore.

  4. RPS non è l'unica metrica significativa. Cose come i client lenti (smartphone 3G, reti congestionate, PC lenti) possono avere un impatto decisamente negativo sui server thread. L'impostazione di laboratorio idealizzata (localhost o switch isolato) non riflette questo.

  5. Lo script FCGI sarà il collo di bottiglia per entrambi i server. Ti suggerirei di utilizzare uno strumento in grado di estrarre più risorse (idealmente un'intera pagina, incluso il contenuto statico) in modo da ottenere un'immagine completa dei tempi di caricamento della pagina.

si potrebbe considerare l'utilizzo di uno degli strumenti di prova "cloud-based", come browsermob.com o loadimpact.com.

Problemi correlati