Best practice per resistere allo scoppio del traffico nei giorni di lancio

Question

Stiamo lavorando su un sito Web per un cliente che (per una volta) dovrebbe ricevere una discreta quantità di traffico il primo giorno. Ci sono comunicati stampa, la gente ci sta bloggando a riguardo, ecc. Sono un po 'preoccupato che finiremo per cadere sul nostro viso il primo giorno. Quali sono le cose principali che vorresti guardare per garantire (in anticipo senza dati reali sul traffico) che puoi rimanere in piedi dopo un grande lancio.

Dettagli: si tratta di uno stack L / A / M / PHP , che utilizza un framework MVC sviluppato internamente. Questo è attualmente in fase di lancio su un server, con Apache e MySQL entrambi su di esso, ma possiamo romperlo se necessario. Stiamo già installando memcached e stiamo eseguendo tutta la memorizzazione nella cache a livello di PHP che possiamo pensare. Alcune pagine sono piuttosto impegnative per le query e stiamo usando Smarty come motore di template. Tieni presente che non c'è tempo per modificare nessuno di questi aspetti principali: questa è la configurazione giusta. A quali tipi di cose dovremmo fare attenzione?

Answer 1

Per preparare o gestire un picco (o picco), determinerei prima se sei pronto attraverso alcuni semplici test delle prestazioni con qualcosa come jmeter .

È facile da configurare e iniziare e ti fornirà le prime metriche se gestirai un carico di picco previsto.

Tuttavia, dati i tuoi limiti di tempo, altri passi da fare sarebbe preparare versioni statiche di contenuto che attirino la massima attenzione (come i comunicati stampa, se il tuo giorno di lancio). Assicurati inoltre di utilizzare al meglio la memorizzazione nella cache lato client (1 richiesta in meno al tuo server può fare la differenza). Il Web già progettato per una scalabilità estremamente elevata e un utilizzo efficace dei contenuti nella cache è il tuo migliore amico in queste situazioni.

Esiste un podcast eccellente sull'alta scalabilità su radio di ingegneria del software sulla progettazione del nuovo sito web Guardian quando le cose si calmano.

buona fortuna per il lancio

Answer 2

Misura prima, poi ottimizza. Hai eseguito test di carico? Dove sono i colli di bottiglia?

Una volta che conosci i tuoi colli di bottiglia, puoi decidere in modo intelligente se hai bisogno di ulteriori DB box o web box, in questo momento dovresti solo indovinare.

Inoltre, come si confrontano i risultati del test di carico con il traffico previsto? Riesci a gestire il doppio del traffico previsto? 5x? Quanto facile / veloce puoi acquisire & amp; rilasciare hardware aggiuntivo? Sono sicuro che il requisito aziendale non deve fallire durante il lancio, quindi assicurati di avere lotti di capacità disponibile, puoi sempre rilasciarlo in seguito quando il carico si è stabilizzato e sai di cosa hai bisogno.

Answer 3

Vorrei almeno scomporre tutto il contenuto statico. Installa un altro vhost da qualche altra parte e carica tutta la grafica / css / js su di esso. È possibile acquistare alcuni cicli extra scaricando la pubblicazione di quel tipo di contenuto. Se sei davvero preoccupato, puoi iscriverti e utilizzare un servizio di distribuzione di contenuti. Ce ne sono molti simili ad Akamai e abbastanza economici.

Un'altra idea potrebbe essere quella di utilizzare apache mod_proxy per mantenere l'output della pagina generata per un determinato periodo di tempo. APC sarebbe anche abbastanza utilizzabile. È possibile utilizzare l'acquisizione del buffer di output + l'ultima volta modificata dei dati correlati nella pagina e utilizzare la versione memorizzata nella cache di APC. Se la pagina non è più valida, ti rigeneri e memorizzi di nuovo in APC.

Buona fortuna, sarà un'esperienza di apprendimento!

Answer 4

Avere un periodo beta in cui consenti a quanti più utenti puoi gestire, misura le prestazioni del tuo sito, risolvi i bug prima di andare in diretta.

Puoi controllare esplicitamente il numero di utenti in una beta privata o una beta semi-pubblica in stile Google in cui ogni utente ha un numero di referral che può offrire ai suoi amici.

Answer 5

Personalmente, farei alcune cose

1) Inserire una sorta di sistema di replica del bilanciamento del carico / database

Ciò significa che puoi distribuire il tuo servizio su più server. Non puoi permetterti di avere più di un server in modo permanente? Usa Amazon E3 - È buono per mettere in atto cose del genere (accendi qualche altro server per gestire il carico)

2) Codice in alcuni "High Load" restrizioni

Ad esempio, se la tua ricerca non è efficiente, disattivalo quando il carico raggiunge un certo livello. " Siamo spiacenti, siamo impegnati, riprovare più tardi per la ricerca "

3) Carica test ... Usa qualcosa come ApacheBench per stress test dei tuoi server.

4) Personalmente, penso che il passaggio a " Keep-Alive " Le connessioni sono migliori. Potrebbe ridurre leggermente le prestazioni complessive, ma - significa che invece di avere qualcosa in cui il sito funziona bene per alcune persone e gli altri ottengono dei timeout, tutti ottengono un servizio incoerente, se arriva a quel livello

Il formato Linux ha fatto un buon articolo su "Come sopravvivere a uno slashdotting" ... che ho trovato utile in passato. È disponibile online come PDF

Answer 6

Primi passi di base per rafforzare il tuo sito per traffico intenso.

1) Utilizza uno strumento a basso costo come https://browsermob.com/ per caricare test posto. Come minimo dovresti guardare 100.000 visitatori unici all'ora. Se ricevi un annuncio dalla home page di MSN, cerca di essere in grado di gestire 500.000 utenti all'ora.

2) Sposta tutti i contenuti grafici / video statici su un CDN. Edgecast e Amazon sono due scelte eccellenti.

3) Utilizzare Jet Profiler per creare un profilo del server MySQL per analizzare le query con prestazioni lente. Piccole modifiche possono avere enormi vantaggi.

Answer 7

Cerca di usare Varnish - è un server proxy inverso nella cache (come calamari, ma molto altro unico scopo). Ho gestito alcuni siti piuttosto grandi dietro di esso, sembrava funzionare davvero bene.