Ci sono un sacco di principi che si applicano a qualsiasi sito web, irrilevanti della pila sottostante:
- strutture utilizzo HTTP caching. Per uno c'è la cache degli user-agent. In secondo luogo, l'intero backbone Web è pieno di proxy che possono memorizzare nella cache le richieste, quindi utilizzarlo a pieno vantaggio. Una richiesta che arriva anche sul tuo server aggiungerà 0 al tuo carico, non puoi ottimizzare meglio di così :)
- corollario al punto precedente, usa CDN (Content Delivery Network, come CloudFront) per il tuo contenuto statico. CSS, JPG, JS, HTML statico e molte altre pagine possono essere servite da un CDN, salvando il server Web da una richiesta HTTP.
- secondo corollario al primo punto: aggiungere suggerimenti di scadenza cache per contenuti dinamici. Anche una breve durata della cache come 10 secondi farà risparmiare un sacco di hit che saranno invece serviti da tutti i proxy che siedono tra il client e il server.
- Ridurre al minimo il numero di richieste HTTP. Sembra semplice, ma è probabilmente l'ottimizzazione meglio trascurata disponibile. In effetti, le best practice di Yahoo la considerano l'ottimizzazione più alta, vedi Best Practices for Speeding Up Your Web Site.Ecco la lista le loro scommesse pratiche:
- Minimizza le richieste HTTP
- Utilizzare un Content Delivery Network
- Aggiungi un scade o un'intestazione Cache-Control
- Componenti Gzip
- ... (l'elenco è piuttosto lungo in realtà, basta leggere il link qui sopra)
Ora dopo aver eliminato il più possi dai risultati superflui, ti sei ancora lasciato ad ottimizzare le richieste che effettivamente colpiscono il tuo server. Una volta che il codice ASP inizia a correre, tutto pallido rispetto alle richieste di database:
- ridurre il numero di chiamate DB per pagina. La migliore ottimizzazione possibile è, ovviamente, non fare la richiesta al DB per iniziare. Alcuni dicono che 4 letture e 1 scrittura per pagina sono le operazioni che il server più carico dovrebbe gestire, altre dicono una chiamata DB per pagina, altre ancora dicono che 10 chiamate per pagina sono OK. Il punto è che meno è sempre meglio di più e le scritture sono molto più costose delle letture. Rivedere il design dell'interfaccia utente, forse che numero di passaggi in un angolo della pagina che nessuno vede non ha bisogno di essere che accurata ...
- assicurarsi che ogni singola richiesta DB si invia al server SQL è ottimizzato . Osserva ogni singolo piano di ricerca, assicurati di avere il covering indexes corretto, assicurati di non eseguire alcuna scansione della tabella, rivedi la tua strategia clustered index design, rivedi tutto il carico di I/O, la progettazione dello storage, ecc. Ecc. Davvero, non c'è scorciatoia si può prendere lei, devi analizzare e ottimizzare il diavolo dal tuo database, è sarà essere il punto di soffocamento.
- eliminare la contesa. Non avere lettori che aspettano scrittori. Per il tuo stack, SNAPSHOT ISOLATION è un must.
- risultati cache. E di solito questo è il caso in cui il biscotto si sbriciola. Progettare una buona cache è in realtà abbastanza difficile da realizzare. Ti consiglierei di guardare la nota fondamentale su Facebook SOCC: Building Facebook: Performance at Massive Scale. Da qualche parte nella diapositiva 47 mostrano come appare una tipica API di Facebook interna:
.
cache_get (
$ids,
'cache_function',
$cache_params,
'db_function',
$db_params);
Tutto è richiesto da una cache, e se non lo trova, richiesto dalla loro fine MySQL indietro. Probabilmente non inizierai con 60000 servers pensato :)
Sullo stack di SQL Server la strategia di caching migliore è quella basata su Query Notifications. È possibile quasi mescolare con LINQ ...
fonte
2010-12-28 00:09:12
+1 Interessante. –