Respuestas:
A continuación se incluye una lista compilada de posibles fuentes de mejora:
General
Almacenamiento en caché
CompiledQuery.Compile()
recursivamente evitando la recompilación de sus expresiones de consultaOutputCacheAttribute
para guardar ejecuciones innecesarias y de acciónActionResultmétodos personalizados si es necesarioRouteNamepara organizar sus rutas y luego usarlo para generar sus enlaces, e intente no usar el método ActionLink basado en el árbol de expresión.PartialViews, evite renderizarlo xxxx veces: si termina llamando al mismo parcial 300 veces en la misma vista, probablemente haya algo mal con eso. Explicación y puntos de referenciaEnrutamiento
Use Url.RouteUrl("User", new { username = "joeuser" })para especificar rutas. ASP.NET MVC Perfomance por Rudi Benkovic
Solución de ruta de caché utilizando este asistente UrlHelperCached ASP.NET MVC Perfomance por Rudi Benkovic
Seguridad
DAL
Balanceo de carga
Utilice proxys inversos para distribuir la carga del cliente en su instancia de aplicación. (Stack Overflow usa HAProxy ( MSDN ).
Utilice controladores asincrónicos para implementar acciones que dependen del procesamiento de recursos externos.
Lado del cliente
Configuración global
Si usa Razor, agregue el siguiente código en su global.asax.cs, de forma predeterminada, Asp.Net MVC se renderiza con un motor aspx y un motor de afeitar. Esto solo usa RazorViewEngine.
ViewEngines.Engines.Clear();
ViewEngines.Engines.Add(new RazorViewEngine());
Agregue gzip (compresión HTTP) y caché estática (imágenes, CSS, ...) en su web.config
<system.webServer>
<urlCompression doDynamicCompression="true" doStaticCompression="true" dynamicCompressionBeforeCache="true"/>
</system.webServer>
<pages buffer="true" enableViewState="false">La sugerencia básica es seguir los principios REST y los siguientes puntos vinculan algunos de estos principios al marco ASP.NET MVC:
Code Climber y esta entrada de blog proporcionan formas detalladas de aumentar el rendimiento de la aplicación.
La consulta compilada aumentará el rendimiento de su aplicación, pero no tiene nada en común con ASP.NET MVC. Acelerará cada aplicación db, por lo que no se trata realmente de MVC.
Esto puede parecer obvio, pero ejecute su sitio en modo Release, no en modo Debug, cuando esté en producción y también durante la creación de perfiles de rendimiento. El modo de liberación es mucho más rápido. El modo de depuración puede ocultar problemas de rendimiento en su propio código.
Al acceder a los datos a través de LINQ confíe en IQueryable ...
¿Por qué usar AsQueryable () en lugar de List ()?
... y palanca un buen patrón de repositorio:
Carga de subregistros en el patrón de repositorio
Esto optimizará el acceso a los datos para garantizar que solo se carguen los datos necesarios y cuando solo se necesiten.
No es una optimización de terremoto, pero yo pensé en tirar esto hacia fuera allí - Uso de CDN para jQuery, etc .
Cita del propio ScottGu: el CDN de Microsoft Ajax le permite mejorar significativamente el rendimiento de los formularios web ASP.NET y las aplicaciones ASP.NET MVC que usan ASP.NET AJAX o jQuery. El servicio está disponible de forma gratuita, no requiere ningún registro y se puede utilizar con fines comerciales y no comerciales.
Incluso usamos el CDN para nuestros elementos web en Moss que usan jQuery.
Además, si usa NHibernate , puede activar y configurar el caché de segundo nivel para consultas y agregar al alcance y el tiempo de espera de las consultas. Y hay un generador de perfiles para EF , L2S y NHibernate: http://hibernatingrhinos.com/products/UberProf . Ayudará a ajustar sus consultas.
También agregaré:
Use Sprites : los Sprites son una gran cosa para reducir una solicitud. Combina todas sus imágenes en una sola y usa CSS para llegar a buena parte del sprite. Microsoft proporciona una buena biblioteca para hacerlo: Sprite y Image Optimization Preview 4 .
Almacenar en caché el objeto del servidor : si tiene algunas listas de referencias o datos que cambiarán raramente, puede guardarlos en la memoria caché en lugar de consultar la base de datos cada vez.
Use ADO.NET en lugar de Entity Framework : EF4 or EF5son excelentes para reducir el tiempo de desarrollo, pero será difícil de optimizar. Es más simple optimizar un procedimiento almacenado que Entity Framework. Por lo tanto, debe utilizar los procedimientos de almacenamiento tanto como sea posible. Dapper proporciona una forma simple de consultar y mapear SQL con muy buen rendimiento.
Página de caché o página parcial : MVC proporciona un filtro fácil para almacenar en caché la página de acuerdo con algunos parámetros, así que úsela.
Reduzca las llamadas a la base de datos : puede crear una solicitud de base de datos única que devuelva varios objetos. Consulte en el sitio web de Dapper.
Siempre tenga una arquitectura limpia : tenga una arquitectura limpia de n niveles, incluso en un proyecto pequeño. Le ayudará a mantener limpio su código y será más fácil optimizarlo si es necesario.
Puede echar un vistazo a esta plantilla " Plantilla MVC Neos-SDI " que creará una arquitectura limpia para usted con muchas mejoras de rendimiento de forma predeterminada (consulte el sitio web MvcTemplate ).
Además de toda la gran información sobre cómo optimizar su aplicación en el lado del servidor, diría que debería echar un vistazo a YSlow . Es un recurso excelente para mejorar el rendimiento del sitio en el lado del cliente.
Esto se aplica a todos los sitios, no solo a ASP.NET MVC.
Una cosa súper fácil de hacer es pensar de forma asíncrona al acceder a los datos que desea para la página. Ya sea que lea desde un servicio web, archivo, base de datos u otra cosa, use el modelo asíncrono tanto como sea posible. Si bien no necesariamente ayudará a que ninguna página sea más rápida, ayudará a que su servidor funcione mejor en general.
1: Obtener tiempos. Hasta que sepa dónde está la desaceleración, la pregunta es demasiado amplia para responder. Un proyecto en el que estoy trabajando tiene este problema preciso; No hay registro para saber cuánto tiempo tardan ciertas cosas; solo podemos adivinar las partes lentas de la aplicación hasta que agreguemos tiempos al proyecto.
2: Si tienes operaciones secuenciales, no tengas miedo de multiprocesar ligeramente. ESPECIALMENTE si están involucradas operaciones de bloqueo. PLINQ es tu amigo aquí.
3: Pregenere sus vistas MVC cuando publique ... Eso ayudará con algunos de los 'primeros éxitos de la página'
4: Algunos abogan por el procedimiento almacenado / ADO ventajas de la velocidad. Otros abogan por la velocidad de desarrollo de EF y una separación más clara de los niveles y su propósito. He visto diseños realmente lentos cuando SQL y las soluciones para usar Sprocs / Views para la recuperación y almacenamiento de datos. Además, tu dificultad para probar aumenta. Nuestra base de código actual que estamos convirtiendo de ADO a EF no está funcionando peor (y en algunos casos mejor) que el antiguo modelo Hand-Rolled.
5: Dicho esto, piense en el calentamiento de la aplicación. Parte de lo que hacemos para ayudar a eliminar la mayoría de nuestros problemas de rendimiento de EF es agregar un método de calentamiento especial. No precompila ninguna consulta ni nada, pero ayuda con gran parte de la carga / generación de metadatos. Esto puede ser aún más importante cuando se trata de modelos de Code First.
6: Como han dicho otros, no use el estado de sesión o ViewState si es posible. No son necesariamente optimizaciones de rendimiento en las que piensan los desarrolladores, pero una vez que comienzas a escribir aplicaciones web más complejas, quieres capacidad de respuesta. El estado de sesión excluye esto. Imagine una consulta de larga duración. Decide abrir una nueva ventana y probar una menos compleja. Bien, es posible que haya esperado con el estado de sesión activado, porque el servidor esperará hasta que se realice la primera solicitud antes de pasar a la siguiente para esa sesión.
7: Minimice los viajes de ida y vuelta a la base de datos. Guarde las cosas que usa con frecuencia pero que no cambiará de manera realista a su .Net Cache. Intente agrupar sus insertos / actualizaciones siempre que sea posible.
7.1: Evite el código de acceso a datos en sus vistas de Razor sin una buena razón. No diría esto si no lo hubiera visto. Ya estaban accediendo a sus datos al armar el modelo, ¿por qué demonios no lo incluían en el modelo?
Solo quería agregar mis 2 centavos. La forma MÁS efectiva de optimizar la generación de rutas URL en una aplicación MVC es ... no generarlas en absoluto.
La mayoría de nosotros sabemos más o menos cómo se generan las URL en nuestras aplicaciones de todos modos, por lo que simplemente usando estática en Url.Content("~/Blahblah")lugar de Url.Action()o Url.RouteUrl()donde sea posible, supera a todos los demás métodos en casi 20 veces e incluso más.
PD. Ejecuté un punto de referencia de un par de miles de iteraciones y publiqué resultados en mi blog si está interesado.
En su clamor por optimizar el lado del cliente, no se olvide de la capa de base de datos. Tuvimos una aplicación que pasó de 5 segundos a cargar hasta 50 segundos durante la noche.
En la inspección, hicimos un montón de cambios de esquema. Una vez que actualizamos las estadísticas, de repente se volvió tan receptivo como antes.
Los siguientes son cosas que hacer
Si está ejecutando su aplicación ASP.NET MVC en Microsoft Azure (IaaS o PaaS), haga lo siguiente al menos antes de la primera implementación.
Hice todas las respuestas anteriores y simplemente no resolvió mi problema.
Finalmente, resolví mi problema de carga lenta del sitio al configurar PrecompileBeforePublish en Publish Profile en true . Si quieres usar msbuild puedes usar este argumento:
/p:PrecompileBeforePublish=trueRealmente ayuda mucho. Ahora mi MVC ASP.NET se carga 10 veces más rápido.