Quali sono le cose di cui abbiamo bisogno per fare in modo che un'applicazione web gestisca un numero elevato di richieste (ad esempio 10000 richieste simultanee).
Aumentare il numero di server e distribuire il carico è un modo, ma ci sono altri modi o configurazioni che possono essere eseguiti sul server delle applicazioni?
Memorizzazione nella cache ragionevole di dati e pagine e ottimizzazione delle query ad alta frequenza. Quei due da soli ti porteranno lontano (sono responsabile di un servizio che vede 1 milione di richieste di dati dinamici al giorno, non enormi, ma neanche minuscole).
Uno dei problemi che vedo più spesso è che le persone si attengono a un modulo normalizzato per i loro database, invece di creare denormalizzato Star-style tavoli.
La normalizzazione non è sempre la scelta migliore quando hai un determinato sottoinsieme di dati che rappresenta il 99% delle tue richieste di dati.
Se parli di 10.000 richieste simultanee, l'intero livello di dati sarà seriamente tassato. Sicuramente vuoi che sia il più snello possibile.
La prima cosa che farei è eseguire alcuni test di carico. Inizia con un carico di base di 500 utenti, quindi aumenta progressivamente il tuo obiettivo di 10.000 utenti ogni pochi minuti.
Durante i test di carico, è necessario monitorare il server di prova e il profilo dell'applicazione.
Spesso è difficile, anche quando si hanno conoscenze di prima mano, dell'applicazione per fare ipotesi corrette su dove ottimizzare. Ecco perché è importante utilizzare gli strumenti.
Se utilizzi VS 2010, nell'edizione Ultimate è disponibile uno strumento di test del carico e di profilazione in grado di simulare un numero variabile di utenti. Esistono anche altri strumenti di altri fornitori. Tali strumenti ti permettono di scrivere scenari per i tuoi utenti virtuali per eseguirli ed eseguirli in massa secondo le specifiche che hai definito.
Ciò ti consentirà di esaminare il consumo di memoria della tua applicazione o il profilo dell'applicazione e di determinare quale sia la causa, se del caso, dei problemi di prestazioni che potresti avere quando sei stato sollecitato da un numero elevato di utenti.
In base a questi test, potresti scoprire che l'applicazione non ha problemi a gestire molti utenti o che non può nemmeno gestire metà del carico.
A seconda di dove si trova il problema, puoi esaminare le misure appropriate per questa specifica area, che si tratti del db, della rete, del codice app, della memoria del server, ecc.
Puoi utilizzare una rete di distribuzione dei contenuti come link per scaricare la maggior parte delle richieste.
Delle tue 10.000 richieste, 1 è per la pagina che servi sul tuo server e le altre 20 circa per immagini, css, javascript. Consentendo a A CDN di gestire tutte queste richieste riduci drasticamente il carico sul tuo server. Ora tutto ciò su cui ti concentri è una piccola parte del traffico che è per la tua vera applicazione web.
Il consiglio su Come fare il tuo carico di lavoro dal database? dovrebbe darti un sacco di materiale su cui riflettere.
Oltre a ciò, prestare attenzione a eventuali ottimizzazioni specifiche della piattaforma standard. Ad esempio, per le applicazioni mod_perl è preferibile avere un proxy inverso di fronte al tuo sito web che serve immagini statiche e che causa i processi mod_perl per non perdere tempo a parlare con client lenti.
Dovresti utilizzare anche load balancer standard, più server web, ecc.
Oltre a ciò, sii molto attento a mantenere la tua architettura il più semplice e diretta possibile. Ho visto persone creare sistemi orribilmente complessi con più livelli di RPC perché "hanno bisogno di scalare" e poi trovano che hanno bisogno di un sacco di hardware a causa del sovraccarico di RPC. Con un'architettura adeguata, dovresti essere in grado di avere un sito tra i primi 1000 siti Web più frequentati utilizzando solo una manciata di server web. Se la tua architettura non è in grado di farlo, le probabilità sono molto buone che il problema è che hai una cattiva architettura, e non che tu abbia troppi utenti.
Detto questo, se hai un sito web molto, molto complesso, con un traffico folle, devi fare qualcosa di molto più complesso. Avrai voglia di distribuire tutto. E vorrai stratificare le cose con le chiamate RPC ai servizi di back-end che a loro volta fanno la stessa cosa. Le chiamate RPC dovrebbero essere il più efficienti possibile. (Google utilizza protobuf per questo. NON usa XML. Se vuoi che sia leggibile, usa qualcosa come JSON, fidati di me.) Inoltre devi assolutamente avere un monitoraggio molto sofisticato sui tuoi sistemi. Se le pagine si rallentano, è necessario essere in grado di tenere traccia di quale chiamata RPC profonda 3 livelli è lenta. Inoltre, se un particolare layer RPC si sta sovraccaricando o rallentando, hai bisogno di strumenti per rilevarlo automaticamente e rintracciare da dove proviene il problema.
Fidati di me quando dico che questo è un problema architettonico complesso. (Ho visto l'infrastruttura di Google per gestirlo. In teoria è molto più semplice della pratica.) Ti prego fidati di me quando ti dico che non vuoi aprire questa lattina di worm fino a dopo aver dimostrato un traffico volume dove ha senso. Se ci provi, probabilmente finirai per essere ancora un'altra società che ti dà una pacca sulla spalla per consegnare con successo 300.000 contatti / ora con 50 server web, senza rendersi conto che 1 dovrebbe essere sufficiente.
Leggi altre domande sui tag web-applications