Cosa devo fare in scala un sito web ad alto traffico?

Question

Quali best practice dovrebbero essere intraprese per un sito web che ha bisogno di "scale-out" per la capacità di gestire? Questo è particolarmente rilevante ora che le persone stanno prendendo in considerazione la nube, ma potrebbero mancare fuori sui fondamentali.

Sono interessato a sentir parlare di tutto ciò che si considera una best practice da compiti a livello di sviluppo, alle infrastrutture, alla gestione.

Answer 1

Design for concorrenza

Cioè, come si sta codifica, piano intorno avere più thread in corso. Pianificare lo stato condiviso (spesso solo il db). Piano per più processi. Piano per la distribuzione fisica.

Questo consente di distribuire il sistema su più macchine, e in più processi con bilanciamento del carico. Esso consente di avere processi ridondanti in esecuzione in caso di guasto, e nel caso in cui è necessario modificare il sistema sul posto, non c'è bisogno di uccidere tutti i servizi di farlo.

Answer 2

Un paio di cose che si potrebbe prendere in considerazione:

• Separazione lettura e scrittura lati della memorizzazione dei dati.
  
  • CQRS / Evento Sourcing
  • CQS
  • Message-anabbagliante / Attori
• Evitando processo condiviso e stato di thread
  • Quindi evitando bloccaggio
  • Si può evitare questo attraverso il sistema di tipo creando le vostre classi, strutture e altri tipi di dati per essere immutabile, cioè non cambia dopo la costruzione. Specialmente per complessi tipi di dati astratti, funziona sorprendentemente bene (per esempio l'implementazione di jQuery)
• Non bloccare le discussioni server Web su IO. Se si utilizza le pagine asincrone uso ASP.Net / azioni con la / task-parallelo libreria di pattern APM (TPL)
• Non salvare carichi di Stato nel dizionario utente-session
  • Questo deve essere mosso tra thread quando migrazioni filetto verificano in IIS.
  • Avere routing intelligente, in modo tale che le risorse non protette / statici non sono serviti con la stessa struttura di applicazione (ad esempio ASP.Net) che aggiungono spese generali. Guardate avere diversi server web, per esempio.
• Scrittura continuazione-passing codice con un flusso di lavoro-pattern asincrona (ad esempio bind (haskell) /callcc/Tasks.ContinueWith/F#'s async)
• Usa teoria delle code per calcolare dove i colli di bottiglia può accadere
• Usa push piuttosto che aggiornamenti di pull-based per leggere-modelli e altre stato dell'applicazione. Per esempio. attraverso RabbitMQ / NServiceBus
• Usare il meno dotato applicabile 'http handler'
• Per i file statici, servire e-tag e le politiche di cache di scadenza per consentire l'infrastruttura Web per il lavoro come si deve (per esempio con proxy squid)
• (assumermi per risolvere i vostri problemi di scala e ottenere tutorial on-site;))

Answer 3

Condividi Niente architettura.

Con questo in mente, e contrariamente a quanto si potrebbe pensare, non saltare a una soluzione scale-out subito. L'overhead off-sistema rispetto a una chiamata in sistema non deve essere sotto-pesato. Per esempio, ci vuole molto più tempo per effettuare una connessione DB attraverso qualsiasi interfaccia di rete di quanto non faccia per effettuare una chiamata locale. Budget quanto tempo nella gestione, il potere, e lo sforzo sintonizzazione è necessaria in scale-out contro il $ in più per un vero e proprio sistema di grandi dimensioni.

Indipendentemente da ciò, c'è ancora un grande valore in "quota di nulla" architetture ed è possibile sovrapporre e scale-out i sistemi quando arriva il momento.

Answer 4

richieste di parallelizzare su più nomi di host

Parte dello standard HTTP è una sezione che dice Web-client potranno richiedere un massimo di 2 sessioni per host DNS. Ecco una soluzione in cui voi e il vostro alias fuori www.domain.com e ottenere una richiesta di concorrenza più elevato, rendendo il caricamento della pagina più veloce:

https: / /stackoverflow.com/questions/3653609/how-do-i-code-my-asp-net-page-to-parallelize-downloads-across-hostnames

In sostanza si tratta di modificare il ASP.NET HTTP Handler di alternare gli host di destinazione si invia ai clienti di, dove ogni ospite è un CNAME per "www".

Answer 5

sicuro, veloce, affidabile DNS

Ho trovato alcuni siti web ad alta capacità che utilizzano il server DNS del registrar, che non aveva SLA per i tempi di attività e prestazioni. Inoltre, i loro server erano situati in India e gli aumenti di latenza solo la possibilità che uno spoofer DNS potrebbe avvelenare, o la cache del provider intermedio del vostro cliente. Questo potrebbe causare anche il traffico SSL protetto per essere reindirizzati senza che nessuno sappia.

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

I utilizzare DynDNS o Neustar per la maggior parte dei miei clienti in quanto hanno un'infrastruttura DNS piuttosto solido (anche se è costoso e non ho altra affiliazione a quelle aziende).

Answer 6

Credo che la chiave sta per essere semplice:

avere il codice semplice. Che significa qualcosa che si guarda e capire. Come si espande e server di cambiamento è necessario sapere che cosa sta succedendo. Potrebbe anche essere necessario aggiungere programmatori che hanno bisogno di capire rapidamente. Ganci e file XML che chiamano codice casuale che non è ovvio è molto cattivo.

Quindi è possibile testare e trovare i problemi.

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

stellarbuild cerchiamo di assicurarsi che i nostri siti web bilancia senza tempi di fermo. Ciò significa che è necessario essere in grado di sapere che cosa il vostro codice fa e dove lo fa. Anche se si sta testando una macchina diversa non si può prendere troppo tempo per scala. La maggior parte delle persone inizia solo quando è quasi troppo tardi, purtroppo. È possibile ottimizzare solo una volta fatto questo, a mio parere.