route - Rendimiento ASP.NET MVC
tag helpers asp net core (16)
Contrariamente a la opinión aceptada, el uso optimizado de formularios web elimina por completo a MVC en términos de rendimiento sin procesar. Webforms ha sido hiper-optimizado para la tarea de servir html mucho más tiempo que MVC.
Las métricas están disponibles en http://www.techempower.com/benchmarks/#section=data-r7&hw=i7&test=db
Cada mvc de comparación se encuentra en los rankings inferiores-medios / bajos-superiores de la lista, mientras que el uso optimizado de los formularios web se ubica en los rankings alto-medio / alto-bajo.
Una validación anecdótica pero muy seria para estas métricas, www.microsoft.com es servida por formularios web no MVC. ¿Alguien aquí cree que no habrían elegido MVC si fuera empíricamente más rápido?
Encontré algunas observaciones alocadas de que ASP.NET MVC es 30 veces más rápido que ASP.NET WebForms. ¿Qué diferencia real de rendimiento hay, se ha medido esto y cuáles son los beneficios de rendimiento?
Esto es para ayudarme a considerar pasar de ASP.NET WebForms a ASP.NET MVC.
Creo que el problema aquí es que no importa cuán rápido ASP.Net MVC sea más rápido que los formularios web antiguos, no hará la diferencia, porque la mayor parte del tiempo se toma en la base de datos. La mayoría de las veces, sus servidores web tendrán un uso de CPU de 0-10% esperando en su servidor de base de datos. A menos que obtenga una gran cantidad de visitas en su sitio web y su base de datos sea extremadamente rápida, probablemente no notará una gran diferencia.
Creo que esta será una pregunta difícil de responder definitivamente, ya que dependerá tanto de A) cómo implementa la aplicación WebForms, y B) cómo implementa la aplicación MVC. En sus formas "crudas", MVC es probablemente más rápido que WebForms, pero años y años de herramientas y experiencia han producido una serie de técnicas para construir aplicaciones rápidas de WebForms. Estoy dispuesto a apostar a que un desarrollador senior de ASP.NET podría producir una aplicación WebForms que rivaliza con la velocidad de cualquier aplicación MVC, o al menos lograr una diferencia insignificante.
La diferencia real -como sugirió @tvanfosson- es la capacidad de prueba y el SoC limpio. Si la mejora del rendimiento es su principal preocupación, no creo que sea una buena razón para lanzarse en WebForms y comenzar a reconstruir en MVC. Al menos hasta que haya probado las técnicas disponibles para optimizar WebForms.
Creo que muchas de las personas que piensan que los WebForms son intrínsecamente lentos o que consumen muchos recursos están culpando en el lugar equivocado. 9 veces de cada 10 cuando me instalan para optimizar una aplicación de formularios web, hay demasiados lugares donde los autores de las aplicaciones no entienden bien el objetivo de ViewState. No digo que viewstate sea perfecto ni nada por el estilo, pero es muy fácil abusar de él, y es este abuso el que está causando el abultado campo viewstate.
Este artículo fue invaluable para ayudarme a entender muchos de estos abusos. http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/truly-understanding-viewstate.aspx
Para hacer una comparación válida entre MVC y WebForms, debemos asegurarnos de que ambas aplicaciones utilicen las arquitecturas correctamente.
Disminuyó una de mis páginas de 2MB de carga útil, a 200k, simplemente eliminando viewstate y haciéndolo soportable programáticamente para trabajar con la salida enviada.
El tamaño solo, a pesar de que el procesamiento fue el mismo, creará grandes mejoras en las conexiones por segundo y la velocidad de las solicitudes.
El rendimiento depende de lo que esté haciendo ... Normalmente MVC es más rápido que asp.net principalmente porque Viewstate está ausente y porque MVC funciona más con Callback que con Postback de manera predeterminada.
Si optimiza su página webform puede tener el mismo rendimiento que MVC, pero será un montón de trabajo.
Además, hay muchos elementos para MVC (y también para Webform) para ayudarlo a mejorar el rendimiento del sitio web, como combinar y minimizar sus CSS y javascripts, agrupar sus imágenes y usarlas como sprites, etc.
El rendimiento del sitio web depende en gran medida de su arquitectura. Una limpieza con una buena separación de preocupaciones le traerá un código más limpio y una mejor idea de cómo mejorar el rendimiento.
Puede echar un vistazo a esta plantilla "Plantilla Neos-SDI MVC " que creará para usted una arquitectura limpia con muchas mejoras de rendimiento por defecto (consulte el sitio web MvcTemplate ).
Empecé a trabajar en MVC hace aproximadamente un año, estaba inspirado pero no impresionado.
Odio el estado de vista y lo veo como la raíz de todo mal en términos de ASP.NET. Es por eso que simplemente no lo uso y para ser honesto, ¿por qué lo harías?
Tomé básicamente el concepto ASP.NET MVC Framework y lo construí a mi manera. Aunque cambié un par de cosas. Construí mi código de envoltura de controlador o código de ruteo de URL alrededor de la recompilación dinámica.
Ahora, iría tan lejos como para decir que las aplicaciones ASP.NET MVC serán más rápidas en función de cómo lo use. Si abandona completamente WebForms, será más rápido porque el ciclo de vida de ASP.NET y el modelo de objetos es enorme.
Cuando estás escribiendo estás creando instancias de un ejército ... no, espera, una legión de objetos que participarán en la representación de tu vista. Esto va a ser más lento que si tuvieras que expresar la cantidad mínima de comportamiento en la página ASPX. (No me importa la abstracción del motor de vista porque la compatibilidad con las páginas ASPX en Visual Studio es aceptable, pero he descartado completamente WebForms como concepto y básicamente cualquier estructura ASP.NET debido a la saturación del código o al no poder cambiar el cosas que conectan mi aplicación).
He encontrado formas de confiar en la recompilación dinámica (System.Reflection.Emit) para emitir objetos especiales y códigos cuando sea necesario. La ejecución de este código es más rápida que la reflexión, pero inicialmente se desarrolló a través del servicio de reflexión. Esto le ha dado a mi framework MVC con sabor un gran desempeño pero también muy tipado estáticamente. No utilizo cadenas y colecciones de pares nombre / valor. En cambio, mis servicios de compilación personalizados van en una reescritura de una publicación de formulario a una acción de controlador que pasa un tipo de referencia. Detrás de la escena hay muchas cosas sucediendo, pero este código es rápido, mucho más rápido que WebForms o MVC Framework.
Además, no escribo URL, escribo expresiones lambda que se traducen en URL que luego dicen qué acción del controlador invocar. Esto no es particularmente rápido, pero es mejor que tener URL rotas. Es como si tuviera recursos tipados estáticamente, así como objetos tipados estáticamente. ¿Una aplicación web estáticamente tipada? ¡Eso es lo que quiero!
Animaría a más personas a probar esto.
Los únicos números concretos que puedo encontrar que provienen del temprano desarrollo ASP.NET MVC están en este hilo del foro:
http://forums.asp.net/p/1231621/2224136.aspx
El propio Rob Connery confirma en cierta medida la afirmación de que ScottGu ha afirmado que ASP.NET MVC puede atender 8000 solicitudes por segundo.
Tal vez Jeff y su equipo pueden dar alguna pista de su desarrollo de este sitio.
Los proyectos creados con visual studio. Una es la plantilla mvc4, otra es WebForm (tranditional). Y cuando realizamos la prueba de carga con WCAT, este es el resultado,
MVC4 es bastante lento que WebForms, ¿alguna idea?
MVC4
- podría obtener alrededor de 11 rps
- rps es bastante bajo, servidor de 2-cpu o 4-cpu
WebForms (aspx)
podría obtener por encima de 2500 rps
el asesino de rendimiento se ha encontrado que es un error de MVC Bata o RC. Y el rendimiento mejoraría una vez que eliminé las cosas de Bundles. Ahora la última versión solucionó esto.
Mis pruebas muestran algo entre 2x y 7x más req / sec en MVC, pero depende de cómo construyas tu aplicación de formularios web. Con solo texto "hello world" en él, sin ningún control del lado del servidor, mvc es alrededor de 30-50% más rápido.
No hemos realizado el tipo de escalabilidad y las pruebas de perforación necesarias para llegar a ninguna conclusión. Creo que ScottGu puede haber estado discutiendo posibles objetivos de rendimiento. A medida que avancemos hacia Beta y RTM, internamente realizaremos más pruebas de perfusión. Sin embargo, no estoy seguro de cuál es nuestra política sobre publicar los resultados de las pruebas de rendimiento.
En cualquier caso, cualquiera de estas pruebas realmente necesita considerar aplicaciones del mundo real ...
Para mí, la mejora real de "rendimiento" en MVC es el aumento de la superficie comprobable de la aplicación. Con WebForms había mucha aplicación que era difícil de probar. Con MVC, la cantidad de código que se puede probar básicamente se duplica. Básicamente, todo lo que no es fácilmente comprobable es el código que genera el diseño. Toda la lógica de su negocio y la lógica de acceso a los datos, incluida la lógica que puebla los datos reales utilizados en la vista, ahora son susceptibles de prueba. Aunque también espero que sea más eficiente: el ciclo de vida de la página se simplifica enormemente y es más compatible con la programación web, incluso si fuera el mismo o un poco más lento, valía la pena cambiar desde una perspectiva de calidad.
Realmente no hay forma de responder esto. MVC utiliza el motor de visualización de formularios web por sí mismo, y puede configurarse para usar cualquier número de motores de vista personalizados, por lo que si desea una comparación de rendimiento deberá ser más específico.
Rick Strahl tiene algunas reflexiones sobre el rendimiento ASP.NET MVC en What''s Ailing ASP.NET Web Forms .
Here hay algunas figuras de hace mucho tiempo ...
Hice un pequeño experimento de prueba de carga de VSTS con un código básico y encontré que el tiempo de respuesta MVC de ASP.NET es dos veces más rápido en comparación con los formularios web de ASP.NET. Arriba está el gráfico adjunto con la trama.
Puede leer este experimento de prueba de carga en detalles de este artículo de CP http://www.codeproject.com/Articles/864950/ASP-NET-MVC-vs-ASP-NET-WebForm-performance-compari
La prueba se llevó a cabo con las siguientes especificaciones usando el software de prueba de carga de VSTS y telerik:
El usuario carga 25 usuarios.
La duración de la prueba fue de 10 minutos.
Configuración de la máquina DELL 8 GB Ram, Core i3
El proyecto fue alojado en IIS 8.
El proyecto fue creado usando MVC 5.
Se asumió la conexión LAN de red. Entonces, esta prueba no tiene en cuenta el retraso de la red por ahora.
Navegador en la prueba seleccionada Chrome e Internet Explorer.
Múltiples lecturas tomadas durante la prueba para promediar eventos desconocidos. Se tomaron 7 lecturas y todas las lecturas se publicaron en este artículo como lectura 1, 2, y así sucesivamente.