Suggerimenti sulle prestazioni del server LAMP [chiuso]


11

Quali suggerimenti sulle prestazioni possono essere offerti a qualcuno che esegue un server LAMP?

Nel caso in cui qualcosa sia specifico della distribuzione, sto prendendo di mira Debian.

Risposte:


26

Dipende molto dal tuo carico di lavoro.

  • per la parte L.

    • avere molta memoria,
    • se riesci a superare i 4 GB, vai a 64 bit.
    • per le partizioni in cui contenuti, registri e dati MySQL utilizzano opzioni di montaggio: noatime, nodiratime.
    • usa unità fisiche / set raid separati, conserva idealmente i dati SQL, i log, i contenuti che servi, ognuno su un mandrino separato.
  • per la parte A del tuo stack - beh forse vuoi sostituirlo completamente con nginx o lighthttpd , o forse lasciare semplicemente Apache per contenuti dinamici e avere un server separato (come quei due o mathopd ) per contenuti statici. Dai un'occhiata qui per ulteriori opzioni. Se eseguirai sia Apache che un altro server nella stessa casella, sarà utile un secondo indirizzo IP. Per ridurre la latenza per l'utente finale, utilizzare http / 1.1 con keep-alive. Prendi in considerazione l'utilizzo di una CDN per il contenuto statico.

  • per la parte M della tua lampada: dai un'occhiata a mysqlperformanceblog . dalla cima della mia testa:

    • registra query lente,
    • dare abbastanza memoria,
    • considera l'utilizzo di innodb.
    • se hai molto testo da cercare, usa sfinge e fai un lavoro batch che ricostruisca l'indice.
    • considera l'idea di uccidere query che durano più di XYZ secondi. È meglio turbare l'1% degli utenti piuttosto che far crollare l'intero sito nell'ora di punta. Ma questo dipende davvero se elabori transazioni in contanti o mostri belle foto.
    • se possibile, utilizzare memcached per memorizzare nella cache il risultato di query SQL più "costose". Ricordare di invalidare la cache quando si cambia il contenuto di SQL. D'altra parte ho abbastanza pochi siti in cui tutti i dati si adattano comodamente alla memoria e per questo MySQL è velocissimo e non c'è bisogno di cache aggiuntiva.
  • per P

    • imposta il timeout di esecuzione per gli script.
    • considerare l'utilizzo di alcune cache acceleratore / opcode PHP . Ero abbastanza soddisfatto di xcache , ma non lo uso ora.
    • se si dispone di elaborazione intensiva della CPU: memorizzare i risultati nella cache e archiviarli in SQL o memcached

Non è davvero un suggerimento sulle prestazioni, ma esegui backup fuori sede. Veramente.


1
se posso aggiungere questo, di recente ho scritto un blog sui backup sicuri con strategie push and pull tramite Amazon S3. non fattibile per i dati bancari, ma tutto ciò di cui ti fiderai amzon dovrebbe andare bene. logaholic.de/2009/05/21/…
Karsten,

ho notato quel post sul blog prima che tu commentassi; -]. bello comunque. puoi sempre crittografare il backup per renderlo più sicuro.
pQd

3

Consiglio davvero di separare MySQL e Apache / PHP su due macchine diverse.

Ad esempio, ho avuto una macchina (C2D E6600) che ha sempre raggiunto il 2.0 e una media di carico superiore. Ho messo MySQL su una seconda macchina (P4C 3Ghz) e dopo che entrambe le medie di carico non sono state superiori a 0,2-0,3. Quindi sono passato da un sito molto lento a un sito veloce con due server con un margine di prestazioni molto elevato.


buon punto. posso solo ipotizzare che il tuo collo di bottiglia avrebbe potuto essere la risposta del sottosistema IO / unità. forse quindi separare i dati su due diverse unità / avere un buon controller del disco potrebbe fare anche il trucco. comunque più memoria, e più cpus è sempre buono, ma poi ottieni anche più possibili punti di errore.
pQd

Bene, non sono così sicuro che si tratti di I / O su disco perché la maggior parte (diciamo il 90%) degli hit SQL sono stati memorizzati nella cache. Stavo pensando ai cambi di contesto della CPU, ma non so se questo possa effettivamente svolgere un ruolo significativo.
Antoine Benkemoun,

1

Per la parte P, è possibile prendere in considerazione la memorizzazione nella cache del codice operativo con APC . Si potrebbe anche considerare mod_fastcgi con php invece di mod_php predefinito.


Mi piace molto eAccelerator. Offre le migliori prestazioni per i miei siti.
TheHippo,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.