Come crescere dalla configurazione di un singolo server

Sto cercando risorse su come far crescere la configurazione del nostro server.

Al momento abbiamo un server dedicato con Rackspace nel Regno Unito con le seguenti specifiche:

HPDL385_G2_PrevGen
HP Single Dual Core Opteron 2214 (2,2 Ghz)
4 GB di RAM
2x 10.000 unità SCSI in RAID 1

Il nostro traffico è fino a 550.000 UV al mese.

Il sito esegue un'installazione PHP e MySQL. Il database ottiene un martellamento assoluto, abbiamo molte query complesse che uniscono tabelle multilpe.

Stiamo utilizzando APC per la memorizzazione nella cache di PHP.

Sto arrivando al punto in cui ho fatto il maggior numero possibile di DB e ottimizzazione delle query e mi chiedo quale dovrebbe essere il prossimo passo ...

Ho esaminato memcache, ma ho l'impressione che per lui sia necessaria una grande quantità di RAM e idealmente una scatola dedicata ...

Quindi è il prossimo passo per avere due scatole; uno per il database, uno per Apache? O c'è un passo che ho trascurato.

Il nostro carico è di solito intorno al segno 2, ma in questo momento è fino a 20!

Alcuni grafici da Munin:

Acquista dell'hardware, ma mettilo nel tuo laboratorio di prova non nel data center. Quindi sollecita la tua applicazione su varie combinazioni hardware / software fino a quando non ne trovi una ragionevole che farà quello che desideri.

Ovviamente dovrai progettare qualcosa che possa creare traffico falso su un database simile alla produzione che esegue una copia di prova della tua app. Ma chi ha detto che sarebbe stato facile.

Se non lo fai e fai semplicemente alcune cose in produzione, non hai idea se funzionerà o meno e potresti aver speso MOLTO sforzo ingegneristico nell'implementare cose come le cache (che arriveranno con la loro giusta quota di bug!) su qualcosa che non aiuta.

Prova, testa e prova di più. Non lanciare modifiche hardware / software nella produzione fino a quando non si ottengono buoni dati sulle prestazioni che dimostrano che è probabile che migliorino significativamente le cose. Lo sforzo di progettazione è costoso, l'hardware di prova non lo è (in particolare).

Memcached è solo un'opzione e probabilmente non è necessario considerarlo fino a quando la cache del database non funziona in modo ottimale. Ciò significa metterlo su un box dedicato (a 64 bit, ovviamente) con una ragionevole quantità di RAM (non 4G - i laptop lo hanno al giorno d'oggi; 32G è decisamente conveniente) e ottimizzarlo in modo appropriato.

Non hai menzionato quanto è grande il tuo database, ma se è del tutto fattibile, vorrai provare a ottenerlo interamente in ram (o almeno nei hot bit). Portare il database interamente in ram farà scomparire del tutto le operazioni di I / O di lettura e quindi smettere di essere un collo di bottiglia.

Profila le tue query sul database. Ci sono strumenti per fare ciò: dovresti essere in grado di simulare il carico di produzione nel tuo ambiente di test. Il trucco è evitare query lente e assicurarsi che quelle eseguite di frequente siano veloci.

Se i tuoi problemi di prestazioni sono correlati alle sincronizzazioni IO, poiché stai facendo troppe transazioni per il database, assicurati di utilizzare un controller raid alimentato a batteria che si sta comportando correttamente (parlane con il tuo fornitore). Offrono molte più operazioni di scrittura IO rispetto a una senza batteria (perché i dati devono solo raggiungere la cache prima che il sistema operativo ottenga la conferma). In alternativa, se i tuoi dati non contano molto, considera di allentare i parametri di durabilità del database (sincronizzazione innodb su commit).

Esaminando le soluzioni di memorizzazione nella cache, come molti altri hanno suggerito qui, puoi aspettarti di finire con circa il 10% del carico che hai oggi, forse meno.

Tuttavia, questo dipende dal tipo di servizi che esegui sul tuo computer. Puoi fare molto con memcached senza molta RAM.

Dovresti provare a profilare quali query del database impiegano più tempo, sia usando il log delle query lente di MySQL (o l'equivalente per il tuo database), o usando uno strumento come mytop . Inoltre, la EXPLAIN SELECTsintassi di MySQL può essere utile.

La memorizzazione nella cache dei risultati di alcune query MySQL selezionate (anche solo per un breve periodo di tempo) può davvero migliorare le tue prestazioni.

Faccio molte prestazioni e ridimensiono il lavoro e quello che ho scoperto è che:

Ogni carico dell'applicazione è unico

Risposte generiche come aggiungere più ram, ottenere un altro server, fare y, provare x sono spesso lezioni di frustrazione e lasciare a configurazioni contorte.

Misura le cose giuste

Una delle maggiori sfide consiste nel determinare quali parametri di riferimento sono importanti. Questo spesso richiede un passo indietro e devi metterti nei panni del tuo cliente. A volte, la progettazione del sito semplicistica cambia e comporta enormi vantaggi per il visitatore web. Ecco perché mi piacciono gli strumenti come YSlow! che si concentrano maggiormente sull'esperienza dell'utente finale anziché sul livello del server. Una volta deciso quale sia il punto di riferimento giusto per il tuo sito, puoi iniziare la sintonizzazione. I benchmark possono essere il tempo totale di caricamento della pagina, la dimensione totale della pagina, l'efficacia della cache, la latenza del sito, ecc. Devi scegliere quello che ha senso per la tua applicazione.

Bulloneria

Uno che stai seguendo i parametri giusti, inizia a un livello molto basso. Mi piace usare sysstat. È possibile ottenere una grande quantità di informazioni da sysstat e aiutarti a distinguere quale sistema potrebbe limitare le prestazioni complessive dell'applicazione. Generalmente, bollo i problemi di prestazioni in:

• stack di rete
• stack di memoria
• disco io
• livello di applicazione
• strato os

Usando sysstat e altri strumenti, puoi iniziare a dividere i peli e trovare il sistema che sta limitando le prestazioni.

Ad esempio, ho visto fallire i server molto caricati a causa della configurazione dell'applicazione. La scarsa memorizzazione nella cache, la mancanza di intestazioni scadute sul contenuto statico, l'utilizzo di HTTP vs include file, ecc., Hanno contribuito a scarse prestazioni dell'applicazione. La risoluzione di questi problemi dell'applicazione non ha richiesto modifiche hardware. In altri casi, ho visto i dischi al massimo nonostante tonnellate di cache. Il passaggio a dischi più veloci ha risolto il problema.

Risciacqua e ripeti

Spesso durante l'ottimizzazione dell'applicazione, si stapperà un collo di bottiglia per trovarne solo un altro. Questo è il motivo per cui ti consiglio di provare a monitorare qualunque cosa tu stia sintonizzando.

Ad esempio, supponi di aver risolto un problema di I / O del disco ma l'app è ancora lenta. Potresti pensare di aver sprecato i tuoi sforzi, ma quello che succede è che hai semplicemente colpito un altro collo di bottiglia. Monitorando attentamente l'IO del disco, si può essere certi di migliorare l'IO del disco anche se i monitor delle prestazioni delle applicazioni importanti non cambiano.

Ottieni gli strumenti giusti

Assicurati di utilizzare gli strumenti giusti per il lavoro. Il monitoraggio, i test, l'analisi comparativa, la profilazione e altre tecniche di ottimizzazione hanno tutti una varietà di strumenti. Trova lo strumento più adatto alla tua situazione.

Regole empiriche

Mentre ogni app è unica, trovo alcuni punti di partenza standard:

• i database di memoria amano la memoria
• il disco tutto tranne il raid 10 può uccidere le prestazioni del database
• ottimizzazioni errate: i grandi valori non si traducono in grandi prestazioni
• applicazione - incolpare il server per un design di app scadente

I tuoi prossimi passi

Se non trovi il collo di bottiglia, l'aggiunta di un server potrebbe non essere di grande aiuto. Per risolvere l'IO del disco potrebbe essere necessario un altro server o SAN. Se hai un collo di bottiglia nella RAM un altro server risolverà il problema solo in quanto aggiunge più RAM. Spostamento piuttosto costoso rispetto all'aggiunta di più RAM al server esistente.

Soluzione rapida

Over deploy. Ho dovuto farlo quando sembra che lo stack dell'applicazione sia il problema. Fondamentalmente caricare su CPU, RAM e IO del disco (RAID 10, 15K SCSI o SSD). Vai in grande sull'hardware e poi inizia la sintonizzazione. Questo ti tiene a galla fino a quando non risolvi i problemi.

Direi che il passo successivo dovrebbe essere la memorizzazione nella cache (memorizzazione nella cache dei dati e / o nella memorizzazione delle pagine a seconda della funzionalità). Se memcached sembra troppo complesso, puoi iniziare con semplici soluzioni di memorizzazione nella cache dei dati come PEAR Cache Lite che richiede solo un paio di righe di codice ma potrebbe fare un'enorme differenza. La memorizzazione nella cache di pagine (o parti di pagina) è supportata , ad esempio, dal motore di template Smarty .

Una volta che la memorizzazione nella cache non la interrompe più, è possibile aumentare la quantità del server in quanto non è rimasto nient'altro.

Se hai abbastanza RAM libera, memcached ti aiuterà anche nella stessa scatola. Prova a memorizzare nella cache diverse query più pesanti e per vedere cosa accadrà. Inoltre, Apache è troppo pesante, usa invece nginx o lighttpd (con l'applicazione PHP che funziona tramite FastCGI, vedi php-fpm ).

Inizia la memorizzazione nella cache, ma ignora MySQL per il momento. Seriouosly.

La regola dovrebbe essere: interrompere una richiesta il prima possibile. Quindi, un proxy inverso o una corretta cache di livello Apache ti darà i migliori risultati, quindi la memorizzazione dei risultati a livello di sql nella cache ALL'INTERNO dell'applicazione, quindi nella cache di livello SQL;)

Prima interrompi una richiesta, meno spese generali hai. Livello di cache di output - nemmeno PHP deve essere eseguito, per così dire.