Risposte:
Di seguito è riportato un elenco compilato di possibili fonti di miglioramento:
Generale
caching
CompiledQuery.Compile()
ricorsivamente evitando la ricompilazione delle espressioni di queryOutputCacheAttribute
per salvare esecuzioni inutili e di azioniActionResultSe necessario, scrivi i tuoi metodi personalizzatiRouteNamedi organizzare i percorsi, quindi di utilizzarli per generare i tuoi collegamenti e prova a non utilizzare il metodo ActionLink basato sull'albero delle espressioni.PartialViews, evita di renderlo xxxx volte: se finisci per chiamare lo stesso parziale 300 volte nella stessa vista, probabilmente c'è qualcosa che non va. Spiegazione e benchmarkRouting
Utilizzare Url.RouteUrl("User", new { username = "joeuser" })per specificare i percorsi. ASP.NET MVC Perfomance di Rudi Benkovic
Risoluzione del percorso della cache utilizzando questo aiuto UrlHelperCached ASP.NET MVC Perfomance di Rudi Benkovic
Sicurezza
DAL
Bilancio del carico
Utilizza i proxy inversi per distribuire il carico del client sull'istanza dell'app. (Stack Overflow utilizza HAProxy ( MSDN ).
Utilizzare i controller asincroni per implementare azioni che dipendono dall'elaborazione di risorse esterne.
Dalla parte del cliente
Configurazione globale
Se si utilizza Razor, aggiungere il codice seguente in global.asax.cs, per impostazione predefinita, Asp.Net MVC esegue il rendering con un motore aspx e un motore rasoio. Questo utilizza solo RazorViewEngine.
ViewEngines.Engines.Clear();
ViewEngines.Engines.Add(new RazorViewEngine());
Aggiungi gzip (compressione HTTP) e cache statica (immagini, css, ...) nel tuo web.config
<system.webServer>
<urlCompression doDynamicCompression="true" doStaticCompression="true" dynamicCompressionBeforeCache="true"/>
</system.webServer>
<pages buffer="true" enableViewState="false">Il suggerimento di base è seguire i principi REST e i seguenti punti legano alcuni di questi principi al framework ASP.NET MVC:
Code Climber e questo post di blog forniscono modi dettagliati per aumentare le prestazioni dell'applicazione.
La query compilata aumenterà le prestazioni dell'applicazione, ma non ha nulla in comune con ASP.NET MVC. Accelererà ogni applicazione db, quindi non riguarda MVC.
Ciò può sembrare ovvio, ma esegui il tuo sito in modalità Rilascio, non in modalità Debug, durante la produzione e anche durante la profilazione delle prestazioni. La modalità di rilascio è molto più veloce. La modalità debug può nascondere problemi di prestazioni nel tuo codice.
Quando si accede ai dati tramite LINQ, fare affidamento su IQueryable ...
Perché usare AsQueryable () invece di List ()?
... e sfruttare un buon modello di repository:
Caricamento dei subrecord nel modello di repository
Ciò ottimizzerà l'accesso ai dati per garantire che vengano caricati solo i dati necessari e solo quando è necessario.
Non un'ottimizzazione sconvolgente, ma ho pensato di lanciarlo là fuori: usa i CDN per jQuery, ecc .
Citazione dello stesso ScottGu: The Microsoft Ajax CDN consente di migliorare significativamente le prestazioni dei moduli Web ASP.NET e delle applicazioni MVC ASP.NET che utilizzano ASP.NET AJAX o jQuery. Il servizio è disponibile gratuitamente, non richiede alcuna registrazione e può essere utilizzato per scopi sia commerciali che non commerciali.
Usiamo persino la CDN per le nostre webpart in Moss che usano jQuery.
Inoltre, se si utilizza NHibernate è possibile attivare e configurare la cache di secondo livello per le query e aggiungere all'ambito e al timeout delle query. E c'è un profiler di calcio per EF , L2S e NHibernate - http://hibernatingrhinos.com/products/UberProf . Aiuterà a mettere a punto le tue domande.
Aggiungerò anche:
Usa gli sprite : gli sprite sono un'ottima cosa per ridurre una richiesta. Unisci tutte le tue immagini in una singola e usi CSS per arrivare a buona parte dello sprite. Microsoft fornisce una buona libreria per farlo: Sprite e Image Optimization Preview 4 .
Cache Il tuo oggetto server : se hai alcuni elenchi di riferimenti o dati che cambieranno raramente, puoi memorizzarli nella memoria invece di interrogare il database ogni volta.
Usa ADO.NET invece di Entity Framework : EF4 or EF5sono ottimi per ridurre i tempi di sviluppo, ma sarà doloroso ottimizzare. È più semplice ottimizzare una stored procedure rispetto a Entity Framework. Quindi dovresti usare le procedure del negozio il più possibile. Dapper offre un modo semplice per eseguire query e mappare SQL con prestazioni molto buone.
Pagina cache o pagina parziale : MVC fornisce alcuni semplici filtri per memorizzare nella cache la pagina in base ad alcuni parametri, quindi usalo.
Riduzione delle chiamate al database : è possibile creare una richiesta di database univoca che restituisce più oggetti. Controlla sul sito Dapper.
Avere sempre un'architettura pulita : avere un'architettura n-tier pulita, anche su un piccolo progetto. Ti aiuterà a mantenere pulito il tuo codice e, se necessario, sarà più facile ottimizzarlo.
Puoi dare un'occhiata a questo modello " Neos-SDI MVC Template " che creerà un'architettura pulita per te con molti miglioramenti delle prestazioni di default (controlla il sito Web MvcTemplate ).
Oltre a tutte le fantastiche informazioni sull'ottimizzazione della tua applicazione sul lato server, direi che dovresti dare un'occhiata a YSlow . È una risorsa eccezionale per migliorare le prestazioni del sito sul lato client.
Questo vale per tutti i siti, non solo per ASP.NET MVC.
Una cosa semplicissima da fare è pensare in modo asincrono quando si accede ai dati desiderati per la pagina. Che tu stia leggendo da un servizio web, un file, una base di dati o qualcos'altro, usa il modello asincrono il più possibile. Anche se non aiuterà necessariamente una pagina a essere più veloce, aiuterà il tuo server a funzionare meglio nel complesso.
1: Ottieni orari. Fino a quando non sai dove si trova il rallentamento, la domanda è troppo ampia per rispondere. Un progetto a cui sto lavorando ha questo preciso problema; Non ci sono registrazioni per sapere quanto tempo impiegano certe cose; possiamo solo indovinare le parti lente dell'app fino a quando non aggiungiamo i tempi al progetto.
2: Se hai operazioni sequenziali, non aver paura di eseguire il multithreading. Soprattutto se sono coinvolte operazioni di blocco. PLINQ è il tuo amico qui.
3: Pregenerare le visualizzazioni MVC durante la pubblicazione ... Ciò contribuirà ad alcuni dei "risultati della prima pagina"
4: Alcuni sostengono la procedura memorizzata / i vantaggi ADO della velocità. Altri sostengono per la velocità di sviluppo di EF e una più chiara seprataion di livelli e il loro scopo. Ho visto progetti molto lenti quando SQL e le soluzioni alternative utilizzavano Sprocs / Views per il recupero e l'archiviazione dei dati. Inoltre, la tua difficoltà di test aumenta. La nostra base di codice attuale che stiamo convertendo da ADO a EF non sta ottenendo risultati peggiori (e in alcuni casi migliori) rispetto al vecchio modello a rotazione manuale.
5: Detto questo, pensa al riscaldamento dell'applicazione. Parte di ciò che facciamo per aiutare a eliminare la maggior parte dei nostri problemi di prestazioni EF è stato l'aggiunta di uno speciale metodo di riscaldamento. Non precompila alcuna query o altro, ma aiuta con gran parte del caricamento / generazione dei metadati. Questo può essere ancora più importante quando si ha a che fare con i modelli Code First.
6: Come altri hanno già detto, non utilizzare lo stato della sessione o ViewState se possibile. Non sono necessariamente ottimizzazioni delle prestazioni a cui pensano gli sviluppatori, ma una volta che inizi a scrivere applicazioni Web più complesse, vuoi reattività. Lo stato della sessione lo preclude. Immagina una query di lunga durata. Decidi di aprire una nuova finestra e provare una meno complessa. Bene, potresti anche aver atteso con lo stato della sessione attivo, perché il server attenderà fino a quando la prima richiesta non viene eseguita prima di passare alla successiva per quella sessione.
7: ridurre a icona i viaggi di andata e ritorno nel database. Salva le cose che usi frequentemente ma che non cambieranno realisticamente nella tua .Net Cache. Prova a raggruppare inserti / aggiornamenti ove possibile.
7.1: Evitare il codice di accesso ai dati nelle viste Razor senza una ragione dannatamente buona. Non lo direi se non l'avessi visto. Stavano già accedendo ai loro dati quando hanno messo insieme il modello, perché diavolo non lo stavano includendo nel modello?
Volevo solo aggiungere i miei 2 centesimi. Il modo più efficace per ottimizzare la generazione della route URL in un'applicazione MVC è ... non generarli affatto.
La maggior parte di noi sa più o meno come vengono generati gli URL nelle nostre app, quindi semplicemente usando statico Url.Content("~/Blahblah")invece Url.Action()o Url.RouteUrl()dove possibile, batte tutti gli altri metodi di quasi 20 volte e anche di più.
PS. Ho eseguito un benchmark di un paio di migliaia di iterazioni e pubblicato risultati sul mio blog, se interessati.
Nel tuo clamore per ottimizzare il lato client, non dimenticare il livello del database. Abbiamo avuto un'applicazione che è durata da 5 secondi per caricare fino a 50 secondi durante la notte.
All'ispezione, abbiamo apportato un sacco di modifiche allo schema. Una volta aggiornate le statistiche, è diventata improvvisamente reattiva come prima.
Di seguito sono cose da fare
Se si esegue l'applicazione ASP.NET MVC su Microsoft Azure (IaaS o PaaS), eseguire almeno quanto segue prima della prima distribuzione.
Ho fatto tutte le risposte sopra e non ha risolto il mio problema.
Infine, ho risolto il mio lento problema di caricamento del sito impostando PrecompileBeforePublish in Publish Profile su true . Se vuoi usare msbuild puoi usare questo argomento:
/p:PrecompileBeforePublish=trueAiuta davvero molto. Ora il mio MVC ASP.NET si carica 10 volte più velocemente.