2009-10-02 14 views
21

Ho un sito Web in PHP, Lighttpd. Utilizza anche MySQL su Centos 5. Ho testato il mio PHP con il codice sottostante con Apache Bench (ab). Ne sono derivati ​​alcuni errori (Richieste non riuscite) che indicavano una lunghezza diversa dal normale. Sono assolutamente sicuro che il mio risultato PHP dovrebbe sempre avere la stessa lunghezza esatta. Ho esaminato i miei registri di Lighttpd e MySQL e i log degli errori e non ho errori.Richieste non riuscite per lunghezza nel mio risultato del test di carico ApacheBench

C'è un modo per controllare esattamente cosa ottiene ab se il risultato ha un'altra lunghezza o c'è un altro modo per scoprire quale è la causa o qual è il risultato "cattivo"?

Ho bisogno di saperlo perché ho bisogno di avere il 100% di buoni risultati.

-bash-3.2# ab -n 500 -c 200 http://domain.com/test/index.php 
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0 
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ 
Copyright 2006 The Apache Software Foundation, http://www.apache.org/ 

Benchmarking domain.com (be patient) 
Completed 100 requests 
Completed 200 requests 
Completed 300 requests 
Completed 400 requests 
Finished 500 requests 


Server Software:  lighttpd/1.4.20 
Server Hostname:  domain.com 
Server Port:   80 

Document Path:   /test/index.php 
Document Length:  15673 bytes 

Concurrency Level:  200 
Time taken for tests: 0.375862 seconds 
Complete requests:  500 
Failed requests:  499 
    (Connect: 0, Length: 499, Exceptions: 0) 
Write errors:   0 
Total transferred:  7920671 bytes 
HTML transferred:  7837000 bytes 
Requests per second: 1330.28 [#/sec] (mean) 
Time per request:  150.345 [ms] (mean) 
Time per request:  0.752 [ms] (mean, across all concurrent requests) 
Transfer rate:   20579.36 [Kbytes/sec] received 

Connection Times (ms) 
       min mean[+/-sd] median max 
Connect:  0 10 9.4  6  30 
Processing:  0 113 133.5  16  342 
Waiting:  0 111 134.3  12  341 
Total:   0 123 138.9  16  370 

Percentage of the requests served within a certain time (ms) 
    50%  16 
    66% 235 
    75% 289 
    80% 298 
    90% 331 
    95% 345 
    98% 365 
    99% 368 
100% 370 (longest request) 

risposta

17

Eseguire ab con il parametro -v 2, che indica il livello di dettaglio 2. Questo eseguirà il dump delle intestazioni di risposta. Se le tue richieste non utilizzano la codifica Chunked, vedrai un'intestazione "Content-Length" che indica la dimensione di ogni risposta.

gw:~$ ab -n 1 -v 2 "http://whatever.com/" 

... 

LOG: header received: 
HTTP/1.0 200 OK 
... 
Content-Length: 1568399 

Se le risposte utilizzano la codifica Chunked, la lunghezza non è nota fino al termine del trasferimento. Solitamente la codifica chunked viene utilizzata solo per le risposte compresse e ApacheBench non esegue la compressione per impostazione predefinita.

Se è è comprimere le risposte per qualsiasi motivo che potrebbe spiegarlo; la lunghezza compressa dipende dal contenuto.

È inoltre possibile utilizzare curl -i e l'opzione --compress per visualizzare le intestazioni di risposta a una singola richiesta con e senza compressione.

+27

** Commento utente anonimo (modifica rifiutata): ** Nota: 'ab' si aspetta che tutte le risposte siano di dimensioni uguali. Se c'è qualche possibilità che il tuo output possa variare di dimensioni, dovresti ignorare "Richieste non riuscite", dato che 'ab' li considererà falliti. – Anne

3

Uso tcpdump

Apri qtà finestre 2 terminale/shell o semplicemente utilizzano lo schermo.

Nella prima finestra, uso tcpdump per acquisire i dati di trasmissione da/verso la scheda di rete (eth0) in un file:

sudo tcpdump -s 9999 -i eth0 -w myfile.txt 

Nella seconda finestra, sparare il vostro comando ab:

ab -n 500 -c 200 http://domain.com/test/index.php 

Quando questo è tutto fatto, analizzare il file con le stringhe e grep:

strings myfile2.txt | grep -C 3 "200 OK" 

Si dovrebbe essere in grado di monito r tutti i segmenti di dati da lì eyeballing o grep'ing i risultati.

+0

ottengo 'tcpdump: ioctl: No such device' messaggio quando si cerca sudo tcpdump –

+0

ho quello che hai scritto e questo sono i risultati: - HTTP /1.0 200 OK Connessione: chiudi X-Powered-By: PHP/5.2.6 Content-type: text/html Come devo interpretare questo risultato? –

+0

Tomaszs: sarà necessario modificare l'identificativo del dispositivo NIC per qualsiasi sistema operativo * nix in esecuzione. en0 su Mac, eth0 su Linux, ecc. HTTP/1.0 200 OK significa che il server Web ha trovato la risorsa richiesta e ha restituito il contenuto. La pagina è riuscita! Devi solo leggere il contenuto di myfile2.txt per vedere dove i guasti stanno entrando nell'immagine. –

1

ab presuppone che tutte le risposte siano uguali. Analizza la lunghezza del contenuto della prima risposta, quindi confronta gli altri con quella.

Dalla pagina man:

Document Length 
    This is the size in bytes of the first successfully returned document. 
    If the document length changes during testing, the response is 
    considered an error. 

Quindi, se la vostra prima richiesta contiene i seguenti dati:

{"hostname":"nodecellar-1-dwfxd","serverip":"10.1.3.3"} 

E il prossimo è:

{"hostname":"nodecellar-1-dwfxd","serverip":"10.1.3.30"} 

ab fallirà con un Errore di lunghezza, poiché l'output è più lungo di un carattere.

Problemi correlati