¿Cómo mejoro el rendimiento de la aplicación ASP.NET MVC?

¿Cómo mejora el rendimiento de su aplicación ASP.NET MVC?

A continuación se incluye una lista compilada de posibles fuentes de mejora:

General

• Utilice un generador de perfiles para descubrir pérdidas de memoria y problemas de rendimiento en su aplicación. personalmente sugiero dotTrace
• 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.

Almacenamiento en caché

• Use CompiledQuery.Compile() recursivamente evitando la recompilación de sus expresiones de consulta
• Caché de contenido que no es propenso a cambiar utilizando OutputCacheAttribute para guardar ejecuciones innecesarias y de acción
• Utilice cookies para acceder a información no confidencial con acceso frecuente
• Utilice ETags y caducidad: escriba sus ActionResultmétodos personalizados si es necesario
• Considere usar el RouteNamepara 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.
• Considere implementar una estrategia de almacenamiento en caché de resolución de ruta
• Coloque código repetitivo dentro de su 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 referencia

Enrutamiento

• 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

• Use la autenticación de formularios, mantenga sus datos confidenciales a los que se accede con frecuencia en el ticket de autenticación

DAL

• Al acceder a los datos a través de LINQ, confíe en IQueryable
• Aproveche el patrón de repositorio
• Perfile sus consultas, es decir, Uber Profiler
• Considere la caché de segundo nivel para sus consultas y agrégueles un alcance y un tiempo de espera, es decir, NHibernate Second Cache

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

• Optimice su lado del cliente, use una herramienta como YSlow para obtener sugerencias para mejorar el rendimiento
• Use AJAX para actualizar los componentes de su interfaz de usuario, evite una actualización completa de la página cuando sea posible.
• Considere implementar una arquitectura pub-sub -es Comet- para la entrega de contenido contra la recarga basada en tiempos de espera.
• Mueva la lógica de generación de gráficos y gráficos al lado del cliente si es posible. La generación de gráficos es una actividad costosa. Al diferir al lado del cliente su servidor de una carga innecesaria, y le permite trabajar con gráficos localmente sin realizar una nueva solicitud (es decir, gráficos Flex, jqbargraph , MoreJqueryCharts ).
• Use CDN para secuencias de comandos y contenido multimedia para mejorar la carga en el lado del cliente (es decir, Google CDN )
• Minify - Compile - su JavaScript para mejorar el tamaño de su script
• Mantenga el tamaño de la cookie pequeño, ya que las cookies se envían al servidor en cada solicitud.
• Considere utilizar DNS y captación previa de enlaces cuando sea posible.

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>

• Eliminar módulos HTTP no utilizados
• Vacíe su HTML tan pronto como se genere (en su web.config) y desactive viewstate si no lo está usando <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:

1. Haga que sus controladores no tengan estado : esta es más una sugerencia de 'rendimiento / escalabilidad web ' (a diferencia del rendimiento a nivel de micro / máquina) y una decisión de diseño importante que afectaría el futuro de sus aplicaciones, especialmente en caso de que se vuelva popular o si necesita algo tolerancia a fallas por ejemplo.
   • No use sesiones
   • No use tempdata, que usa sesiones
   • No intente 'almacenar en caché' todo 'prematuramente'.
2. Autenticación de formularios de uso
   • Mantenga sus datos confidenciales de acceso frecuente en el ticket de autenticación
3. Utilice cookies para acceder a información no confidencial con acceso frecuente
4. Haga que sus recursos se puedan almacenar en caché en la web
   • Utiliza ETags
   • Usar vencimiento
   • Escriba sus clases de ActionResult personalizadas si es necesario
   • Utiliza proxies inversos
5. Compila tu JavaScript. También hay una biblioteca del compilador de Closure para hacerlo (seguro que hay otros, solo busque el 'compilador de JavaScript' también)
6. Utilice CDN (Content Delivery Network), especialmente para sus archivos multimedia grandes, etc.
7. Considere diferentes tipos de almacenamiento para sus datos, por ejemplo, archivos, almacenes de clave / valor, etc., no solo SQL Server
8. Por último, pero no menos importante, pruebe el rendimiento de su sitio web

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é:

1. 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 .

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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?

1. Implementar Gzip.
2. Utilice la representación asincrónica para vistas parciales.
3. Minimiza las visitas a la base de datos.
4. Use una consulta compilada.
5. Ejecuta un generador de perfiles y descubre golpes innecesarios. Optimice todos los procedimientos almacenados que tardan más de 1 segundo en devolver una respuesta.
6. Utiliza el almacenamiento en caché.
7. Utilice la optimización de minificación de paquetes .
8. Use las utilidades HTML 5, como el caché de sesión y el almacenamiento local para contenido de solo lectura.

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

1. Caché en modo kernel
2. Modo de canalización
3. Eliminar módulos no utilizados
4. runAllManagedModulesForAllRequests
5. No escribas en wwwroot
6. Eliminar los motores de visualización y el lenguaje no utilizados

Usar Bundling and Minification también lo ayuda a mejorar el rendimiento. Básicamente reduce el tiempo de carga de la página.

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.

• Escanee su código con el analizador de código estático en busca de cualquier tipo de deuda de código, duplicación, complejidad y seguridad.
• Siempre active Application Insight y monitoree el rendimiento, los navegadores y los análisis con frecuencia para encontrar los problemas en tiempo real en la aplicación.
• Implemente Azure Redis Cache para datos de cambios estáticos y menos frecuentes, como imágenes, activos, diseños comunes, etc.
• Confíe siempre en las herramientas APM (Application Performance Management) proporcionadas por Azure.
• Consulte el mapa de la aplicación con frecuencia para investigar el rendimiento de la comunicación entre las partes internas de la aplicación.
• Supervise el rendimiento de la base de datos / VM también.
• Use Load Balancer (Escala horizontal) si es necesario y dentro del presupuesto.
• Si su aplicación tiene el público objetivo en todo el mundo, use Azure Trafic Manager para manejar automáticamente la solicitud entrante y desviarla a la instancia de aplicación más disponible.
• Intente automatizar la supervisión del rendimiento escribiendo las alertas basadas en el bajo rendimiento.

Use la última versión de la Biblioteca de tareas paralelas (TPL) , de acuerdo con la versión .Net. Tiene que elegir los módulos correctos de TPL para diferentes propósitos.

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=true

Realmente ayuda mucho. Ahora mi MVC ASP.NET se carga 10 veces más rápido.