Scaling LAMP

Question

Ho un client con un sito Web LAMP che serve principalmente video. Attualmente è su un server con tutti i componenti. Sta avendo dei problemi di ridimensionamento. Quali sono alcune delle tecniche che possono essere utilizzate per aiutare.

Ho usato la separazione del DB su un altro server con una Ethernet GB tra esso e il server web. Forse aggiungendo più server Web con un certo bilanciamento del carico e altri server MySQL con replica?

Vorrei alcuni esempi medi, grandi, super grandi su come ridimensionare se possibile.

Il video arriva in realtà come immagini jpg. Simile a questo sito Web:

http://www.webcams.travel/webcam/1170170095

E per aggiungere alcuni dettagli. Immagino che il numero massimo di visitatori all'ora sarebbe 1000 e penso che sarebbe fortunato ad averlo. Forse più vicino a 1000 al giorno.

Answer 1

I consigli su CloudFront e MemCache ecc. sono tutti validi, supponendo che affrontino la radice dei problemi di prestazioni.

Dal lato del database: profilo, profilo, profilo. Spostare il DB su un server separato è stato (probabilmente) un buon passo, ma se non hai creato il profilo delle query in esecuzione su questa istanza di DB, non sai cosa devi migliorare.

Inizia facendo una EXPLAIN sulle query più comuni e verifica se stai eseguendo scansioni sequenziali non necessarie su tabelle di grandi dimensioni o in crescita. Indice come necessario.

Ci sono delle query che restituiscono colonne non utilizzate?

Sei preoccupato, come altri commentatori, di pubblicare i tuoi contenuti grafici / video dal database? I file devono essere conservati nel filesystem e serviti da lì.

Tutti i tuoi tavoli sono MyISAM? Le tabelle aggiornate di frequente possono mostrare un miglioramento delle prestazioni spostandole in InnoDB , dove possono beneficiare del blocco a livello di riga (anziché il blocco a livello di tabella di MyISAM).

Questi sono solo semplici consigli generali - senza ulteriori dettagli su esattamente cosa è lento, è difficile offrire qualcosa di più profondo.

Answer 2

Prima di tutto, sono d'accordo che devi sapere qual è il collo di bottiglia prima di provare a ridimensionare. Ecco alcuni suggerimenti per iniziare:

1. Ottieni video dal database. Non vedo come ciò avrebbe senso in qualsiasi situazione.

2. Aggiungi un altro server per server solo il contenuto video e lascia l'HTML / l'applicazione a quello originale. Ciò non solo riduce il carico, ma crea un miglioramento delle prestazioni sul lato client superando qualsiasi Limiti della connessione HTTP .

3. Cache - Questo può significare Memcahce o semplicemente pre-compilare l'output HTML invece che dinamicamente elaborandolo per ogni richiesta.

4. Se sei abbastanza fortunato da raggiungere il "super grande" potresti pensare a un CDN . Sono sicuro che incontrerai molti altri ostacoli prima di allora però.

Buona fortuna.

Answer 3

Devi capire esattamente qual è il problema: non esiste una soluzione generale.

È necessario creare un ambiente di test delle prestazioni con hardware reale e qualcosa che possa simulare molti client. Questo può essere piuttosto costoso.

Se il problema è il database (quale potrebbe essere), la soluzione è spesso quella di dividerlo in più database ciascuno contenente parte dei dati.

Ma non immaginerei che qualsiasi persona sana di mente memorizzerebbe video su MySQL - se lo fa, allora un refactoring potrebbe essere in ordine.

Answer 4

Profilo per vedere quanto caricano effettivamente varie parti del suo sito.

Suppongo che la maggior parte del carico stia effettivamente servendo i video - usa un proxy per reindirizzare questo lavoro su un secondo (, terzo, quarto ...) server.

Answer 5

Le risposte di Barrett sono praticamente ciò che vorrei fare: identificare i colli di bottiglia, guardare memcached, spostare il DB su un server separato dai servizi web, ecc.

Aggiungerei che Amazon ha un nuovo servizio chiamato CloudFront che offrirà contenuti da aree geografiche server vicini. Non l'ho ancora provato, ma potrebbe essere un modo per distribuire il carico a un costo relativamente basso.

Inoltre, guarda le presentazioni di Livejournal e Facebook su come ridimensionano i loro sistemi, possono fornire alcune informazioni a seconda di come sono strutturate le tue applicazioni.

Answer 6

Dovresti profilare l'applicazione con cui cominciare e scoprire dove si trovano i colli di bottiglia - se si tratta di PHP, usare qualcosa come xdebug sarebbe un buon inizio. È possibile che passi molto tempo a serializzare i dati o a parlare con un database, quindi forse la memorizzazione nella cache con Memcached può essere di aiuto.

In secondo luogo, se si utilizza MySQL, attivare il registro delle query lente di MySQL (log_slow_queries in my.cnf); questo può essere usato per darti un'idea di quali sono le costose query del database e una volta che sai che puoi mirare a ottimizzarle tramite EXPLAIN < > come è già stato menzionato. Potrebbe essere solo necessario aggiungere alcuni indici al database, a quel punto tornerà rapidamente. Esistono altri parametri my.cnf pertinenti, ad es. query di log che non utilizzano un indice.

In terzo luogo, cerca strumenti come il plug-in firefox di velocità della pagina di Yahoo: fornirà alcuni suggerimenti (ad esempio scaricando contenuto statico, comprimendo roba che stai restituendo, assicurati di avere intestazioni in scadenza ecc.). Forse i server stessi non sono il collo di bottiglia e il rendering delle pagine impiega molto tempo a causa della dipendenza da una terza parte (JS esterno, pubblicità, flash ...).

Dovrai avere un'idea di quanto sia occupato il tuo server di database, rispetto al tuo web server, per sapere dove devi aggiungere altro hardware (cioè hai bisogno di più server web con un bilanciamento del carico front-end, o hai bisogno di più server di database con replica o entrambi?).

Sono sicuro che ce ne sono molti altri che si possono dire ...