ab è un po' fastidioso se il tuo sito ha bisogno di cookie, ecc, ab è troppo semplice.
Fondamentalmente, dalla mia esperienza nel riparare diversi siti Web PHP che implodono, di solito va così :
1) Le persone usano MySQL
Puoi usare totalmente MySQL, facebook e flickr fallo (i fan di mysql li adorano) SE CONOSCI I GOTCHAS che sono :
- Se hai una tabella MyISAM non di sola lettura e qualsiasi query più lunga di 100 us (anche selezioni) sei morto
Su un sito che ho riparato, il ragazzo aveva affittato un server double-quad-core perché "il suo sito ha bisogno di energia". Guardo il suo sito, guardo il mio sito precedente con> 100.000 membri e un tracker torrent che girava su un server Via C7 micro-half-pizzabox, e gli dico, il tuo sito funziona bene sul Celeron 300 che è nel mio seminterrato , e questo è persino eccessivo, te lo posso affittare a metà del prezzo del tuo Xeon, lol.
Si è scoperto che il ragazzo era un bravo sviluppatore e un bravo ragazzo, ma faceva schifo con MySQL, quindi il suo sito aveva la tipica query di ricerca dall'inferno che può uccidere qualsiasi sito web :
- 10 query di ricerca dall'inferno al secondo (aveva circa 300.000 membri sul suo sito illegale di warez)
- la query di ricerca dall'inferno impiega circa 0,1 - 0,2 secondi
- un piccolo flusso di aggiornamenti simultanei alla stessa tabella MyISAM per ravvivare le cose
=> serializzazione totale (blocchi di scrittura MyISAM) di tutte le query. 1 core al 100%, 7 core inattivi, loadavg> 1000 (sì, stava usando apache), tempi di pagina> 30 secondi, funziona.
La correzione è stata semplice:ottimizza la query di ricerca dall'inferno, correggi il punto 2) di seguito, passa a InnoDB, passa a lighttpd. loadavg è sceso a 0.02
2) AGGIORNAMENTI
Nessuno è interessato ai contatori di pagina. Emetti 1 AGGIORNAMENTO per ogni visualizzazione di pagina e sei morto. Aggiungi un po' di MyISAM per più effetti. Anche un killer su InnoDB, non sul blocco, piuttosto sull'IO del disco di sincronizzazione attende.
3) TESTO COMPLETO
- MyISAM non utilizzabile per tabelle di lettura-scrittura a causa del blocco.
- MyISAM è affidabile come un ramdisk (in effetti, meno:hai bisogno di un arresto anomalo del sistema operativo per corrompere un ramdisk, corrompere le tabelle MyISAM richiede solo un arresto anomalo di MySQL o semplicemente colpirlo troppo contemporaneamente, otterrai "unknown table engine errore", l'ho visto molte volte)
- FULLTEXT non disponibile su InnoDB
- Qualsiasi inserimento in un indice FULLTEXT innesca quasi una ricostruzione completa dell'indice (quando ho inserito un post nel forum, si stavano ricostruendo 400 MB di indice)
==> Se hai bisogno di indicizzazione del testo completo, prestazioni e affidabilità, usa Sphinx o Xapian.
Non ho provato Sphinx (la gente ne parla bene), ma Xapian cerca felicemente in 4 GB di testo in un attimo.
4) Le persone usano apache.
Questo si combina piacevolmente con i punti sopra.
A differenza di un server adeguato come lighttpd il cui utilizzo della CPU non è rilevabile (lo scadente Via C7 serviva 100 hit HTTP / se lighttpd utilizzava meno dell'1% della CPU), apache ucciderà la tua scatola.
Quando MySQL inizia a morire (muore facilmente), i client iniziano a premere forte F5 e presto si hanno circa 1000 processi Apache, ognuno con un interprete PHP e ogni interprete PHP con una connessione MySQL inattiva, in attesa di un blocco MyISAM, tranne uno, che sta eseguendo un banale AGGIORNAMENTO del contatore delle visualizzazioni di pagina, ma richiede un po' di tempo, perché il server è andato a pranzo a scambiarsi, a causa dei 1000 processi apache e 1000 php e 1000 mysql.
Lighttpd non utilizza cpu per le pagine statiche. L'unico modo per lighttpd di saturare la tua CPU è se lo colpisci duramente con apachebench a circa 20K richieste/s. Quindi Lighttpd parla con alcuni, come 10 backend php-fcgi (2-4 per core va bene) che parlano con alcune connessioni MySQL. Di conseguenza, tutto è molto più veloce e, quando è sovraccarico, si degrada con grazia, non in modo esplosivo.
Per arrivare alla domanda originale, devi assolutamente profilare le tue query SQL. Aggiungi un registro delle query alla tua applicazione PHP che mostra (solo a te), l'elenco delle query e il tempo che impiegano, e anche il tempo dall'inizio dello script PHP alla sua fine (le intestazioni/piè di pagina sono un buon posto per questo).
Per una pagina complessa (esclusa la ricerca) ti aspetteresti circa 3 ms MySQL e 3 ms PHP, questo è un buon obiettivo. Ovviamente hai bisogno di una cache del codice compilato in PHP.
Per il carico attuale, ci sono un paio di cose che puoi fare. Le risposte più costose, ma più dettagliate, verranno fornite tramite un'applicazione aziendale come "Gomez".
Tuttavia, se stai cercando di farlo da solo, consulta le mie risposte precedenti di seguito o utilizza utilità della shell come:htop, top, w e utilizza Apache server-status
Risposte precedenti prima della revisione della domanda:
Quello che stai chiedendo a volte viene chiamato profiling dell'applicazione.
Devi creare una formula di memoria approssimativa come:
httpd ram + utilizzo della memoria php + utilizzo del processo mysql =footprint di memoria totale della richiesta
Avrai anche bisogno di una formula della CPU, ma puoi anche guardare in alto durante un test di carico.
Apache ha il comando 'ab'.
"ab è uno strumento per il benchmarking del tuo server Apache Hypertext Transfer Protocol (HTTP). È progettato per darti un'idea di come si comporta la tua attuale installazione di Apache. Questo mostra in particolare quante richieste al secondo è in grado di servire la tua installazione di Apache. " http://httpd.apache.org/docs/2.0/programs/ab.html
Ecco una riga di comando generica del benchmark 'ab':
ab -n 10 -c 1 http://www.yoursite.com/
# qty 10 total requests, 1 request at a time
La strategia consiste nel testare il carico per processo (utente) sulla tua applicazione dalla richiesta della pagina Web fino al completamento. Se riesci a identificare la quantità di RAM utilizzata da Apache, PHP e MySQL per ogni richiesta, puoi identificare rapidamente la capacità del tuo sistema.
Probabilmente dovrai utilizzare una combinazione di strumenti diagnostici come vmstat o top o iostat o ps, ecc. per acquisire un'istantanea di ciò che una serie di richieste richiederà dal tuo sistema.
Infine, vorrai installare Xdebug. Questo strumento ti aiuterà a profilare il lato php dell'applicazione.http://xdebug.org/
Ecco il tutorial di IBM sull'installazione di Xdebug:
http://www.ibm.com/developerworks/opensource/library/os-php-fastapps2/