Cosa devo fare per ridimensionare un sito Web ad alto traffico?

Quali sono le migliori pratiche da adottare per un sito Web che deve "ridimensionarsi" per gestire la capacità? Ciò è particolarmente rilevante ora che le persone stanno prendendo in considerazione il cloud, ma possono perdere i fondamenti.

Sono interessato a conoscere qualsiasi cosa tu consideri una best practice dalle attività a livello di sviluppo, all'infrastruttura, alla gestione.

Progettare per la concorrenza

Cioè, mentre stai programmando, pianifica di avviare più thread. Pianifica lo stato condiviso (spesso solo il db). Pianificare più processi. Pianificare la distribuzione fisica.

Ciò consente di distribuire il sistema su più macchine e su più processi con bilanciamento del carico. Consente di eseguire processi ridondanti in caso di errore e nel caso in cui sia necessario modificare il sistema sul posto, non è necessario interrompere tutti i servizi per farlo.

Alcune cose che potresti considerare:

• Separare i lati di lettura e scrittura della memoria dei dati.
  
  • CQRS / Sourcing di eventi
  • CQS
  • Message-passing / Attori
• Evitare il processo condiviso e lo stato del thread
  • Quindi evitando il blocco
  • Puoi evitarlo attraverso il sistema di tipi creando immutabili classi, strutture e altri tipi di dati, ovvero non modificabili dopo la costruzione. Soprattutto per tipi di dati astratti complessi, funziona sorprendentemente bene (ad esempio l'implementazione di jQuery)
• Non bloccare i thread del server Web su IO. Se si utilizza ASP.Net, utilizzare pagine / azioni asincrone con il modello APM / libreria di task-parallel (TPL)
• Non si salva un sacco di stato nel dizionario della sessione utente
  • Questo deve essere spostato tra i thread quando si verificano migrazioni dei thread in IIS.
  • Avere un routing intelligente, in modo tale che le risorse non sicure / statiche non vengano fornite con lo stesso framework applicativo (ad es. ASP.Net) che aggiunge overhead. Guarda ad avere server web diversi, per esempio.
• Scrivere codice di continuazione con un flusso di lavoro asincrono (ad es. Bind (haskell) /callcc/Tasks.ContinueWith/F#'s async)
• Usa la teoria delle code per calcolare dove possono verificarsi i colli di bottiglia
• Utilizzare aggiornamenti push anziché pull per leggere i modelli e altri stati dell'applicazione. Ad esempio tramite RabbitMQ / nServiceBus
• Utilizza il 'gestore http' meno applicabile
• Per i file statici, servire e-tag e criteri di scadenza della cache per consentire all'infrastruttura web di funzionare come dovrebbe (ad esempio con proxy squid)
• (Assumimi per risolvere i tuoi problemi di ridimensionamento e ottenere tutorial in loco;))

Condividi Nothing architecture.

Con questo in mente e contrariamente a quanto potresti pensare, non saltare subito a una soluzione scalabile. L'overhead fuori dal sistema rispetto a una chiamata all'interno del sistema non deve essere sottovalutato. Ad esempio, ci vuole molto più tempo per stabilire una connessione DB attraverso qualsiasi interfaccia di rete rispetto a una chiamata locale. Preventiva il tempo necessario per la gestione, la potenza e la messa a punto del ridimensionamento rispetto ai $ in più per un vero sistema di grandi dimensioni.

Indipendentemente da ciò, io ho ancora un grande valore nelle architetture "condividi nulla" e puoi, quando sarà il momento, puoi stratificare e ridimensionare i tuoi sistemi.

Parallelizza le richieste su più nomi host

Parte dello standard HTTP è una sezione in cui si dice che i client Web richiederanno un massimo di 2 sessioni per host DNS. Ecco una soluzione in cui tu e il tuo alias www.domain.com ottenete una maggiore concorrenza per le richieste, velocizzando il caricamento della pagina:

/programming/3653609/how-do-i-code-my-asp-net-page-to-parallelize-downloads-across-hostnames

Fondamentalmente comporta la modifica del gestore HTTP ASP.NET per alternare gli host di destinazione a cui si inviano i client, dove ogni host è un CNAME su "www".

DNS sicuro, veloce e affidabile

Ho trovato alcuni siti Web ad alta capacità utilizzando il server DNS del registrar, che non aveva SLA per uptime o prestazioni. Inoltre, i loro server si trovavano in India e la sola latenza aumenta le possibilità che uno spoofer DNS possa avvelenare la cache del tuo cliente o dell'ISP intermedio. Ciò provocherebbe il reindirizzamento anche del traffico protetto da SSL senza che nessuno lo sapesse.

La velocità DNS influisce anche sul tempo di caricamento iniziale del server, prima che i record vengano memorizzati nella cache.

Uso DynDNS o Neustar per la maggior parte dei miei clienti poiché dispongono di un'infrastruttura DNS piuttosto solida (anche se è costosa e non ho altre affiliazioni con quelle aziende).

Penso che la chiave sarà semplice:

Hai un codice semplice. Ciò significa qualcosa che guardi e capisci. Mentre espandi e cambi server devi sapere cosa sta succedendo. Potrebbe anche essere necessario aggiungere programmatori che devono capire rapidamente. Hook e file XML che chiamano codice casuale che non è ovvio è molto male.

Quindi puoi testare e trovare i problemi.

Guarda qui: http://blog.servint.net/2013/08/27/going-big-how-to-scale-a-website-part-1-infrastructure-that-scales/

Noi di stellarbuild cerchiamo di assicurarci che i nostri siti Web si ridimensionino senza tempi di inattività. Ciò significa che devi essere in grado di sapere cosa fa il tuo codice e dove lo fa. Anche se stai testando una macchina diversa non puoi impiegare troppo tempo per ridimensionarla. Molte persone iniziano solo quando è quasi troppo tardi, purtroppo. A mio avviso, puoi ottimizzare solo una volta che lo fai.