Richiedi Informazioni

Come scalare un server dedicato LAMP a migliaia di accessi contemporanei.

Nel corso degli anni mi è capitato di dover dimensionare delle server dedicati ad applicazioni web con esigenze di ridondanza e concurrency, diciamo così, notevoli.

E, quando si decide di gestire migliaia di acessi contemporanei, le cose non sono proprio semplicissime e non lo sono in special modo se i server devono eseguire delle infrastrutture LAMP.

Ho scoperto tuttavia che si, è possibile fare in modo che un singolo server dedicato possa ospitare un livello di traffico così elevato senza necessariamente scalare ad architetture multi-tier a meno di non aver bisogno di ridondanza.

Ecco alcuni consigli senza un particolare ordine di priorità:

1) non servire file statici con Apache/PHP
L’accoppiata Apache/PHP è in grado di mangiar via tanta RAM ed una buona fetta della potenza di calcolo.

Se vuoi servire migliaia di connessioni con un server, ti consiglio di spostare tutti i file statici all’interno di una CDN, oppure di servirli separatamente con Nginx.

2) usa una opcode cache
PHP è un linguaggio interpretato, se non utilizzi una cache il tuo script viene interpretato ogni volta che viene richiamato da Apache, il processo porta via molto tempo.

Ti consiglio di usare un opcode cache (come PHP/APC) per fare si che il sistema utilizzi molte meno risorse processore a fronte di un (leggero) aumento di utilizzo in RAM. Gli script gireranno più veloci e termineranno prima, ritardando il più possibile l’accodamento delle risorse.

3) usa i bilanciatori di carico e separa i flussi
Per poter scalare, è necessario utilizzare un bilanciatore di carico che distribuirà i flussi di richieste su più front-end. La cosa è ancora più vera se separi i flussi di file dinamici (php) da quelli statici (immagini, file javascript ect).

Configurando correttamente un bilanciatore di carico potresti per esempio fare atterrare le immagini su un front-end apposito servito da nginx, i file javascript e css su CDN, inoltrare i pannelli di controllo verso front-end ad-hoc.

4) non scrivere/leggere direttamente dal database
Se la tua applicazione php scrive e legge in modo massiccio dal database, per ogni volta che i tuoi script verranno chiamati questi dovranno attendere la latenza del database per poter completare. Questo è ancora più vero se il database è una macchina separata.

Il suggerimento che posso darti è di utilizzare memcache/redis come “storage temporaneo” per tutte le operazioni che non richiedono necessariamente un accesso al database (ad esempio, la gestione delle sessioni).

Inoltre sistemi come memcache e redis si prestano bene per la realizzazione di sistemi di “accodamento”. Le operazioni di scrittura che dovrebbero andare al db verranno accodate in questa sorta di cache e poi le scritture verranno effettuate ad intervalli determinati con un apposito job che legge la coda, ne trasferisce il contenuto in db e la svuota.

5) usa una front-end cache
Le front-end cache come (ad esempio) varnish, sono in grado di prevenire che lo stack Apache/Php (e in seguito MySQL) vengano colpiti da un numero eccessivo di richieste simili tra di loro.

Se una richiesta è simile a quella precedente, varnish fornirà la copia in memoria ed eviterà di contattare i server alle spalle, questo conferirà solidità all’infrastruttura.

Occhio però, il dimensionamento ed i test di carico devono essere fatti senza tenere conto di varnish, questo per evitare che un’operazione di manutenzione sulla front-end cache porti al down dell’intero sistema.

6) fai attenzione allo stack TCP
Se i tuoi front-end ricevono molte richieste per secondo, potresti saturare le porte TCP.

Ti consiglio di verificare attentamente per quanto tempo le porte rimangono in stato di WAIT e di minimizzare (nei limiti del ragionevole) questo tempo.

7) scrivi del SQL che sia *safe* dal punto di vista della replica
Se scrivi del SQL in modo disaccorto potresti non riuscire a far funzionare le repliche (master-master o master-slave).

Questo potrebbe diventare un ostacolo nel momento in cui la tua applicazione dovesse aver bisogno – malgrado gli accorgimenti già presi – di scalare su più back-end SQL.

Se quello che hai letto ti trova daccordo, tieni presente che non devi necessariamente effettuare queste configurazioni da solo ed in prima persona.

Se hai bisogno di un supporto, puoi contattarci e chiederci di dimensionare per te i tuoi server dedicati. La nostra esperienza quotidiana, che poi si riflette anche nei punti che ti ho elencato sopra, potrebbe esserti di aiuto e farti risparmiare tempo e denaro.