Encontré algunos comentarios descabellados 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 y cuáles son los beneficios de rendimiento?

Esto es para ayudarme a considerar pasar de ASP.NET WebForms a ASP.NET MVC.

No hemos realizado el tipo de pruebas de escalabilidad y rendimiento necesarias para llegar a conclusiones. Creo que ScottGu pudo haber estado discutiendo posibles objetivos de rendimiento. A medida que avanzamos hacia Beta y RTM, internamente realizaremos más pruebas de rendimiento. Sin embargo, no estoy seguro de cuál es nuestra política sobre la publicación de resultados de pruebas de rendimiento.

En cualquier caso, estas pruebas realmente deben considerar aplicaciones del mundo real ...

Creo que esta será una pregunta difícil de responder definitivamente, ya que mucho dependerá de A) cómo implemente la aplicación WebForms y B) cómo implemente la aplicación MVC. En sus formas "sin procesar", 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 crear aplicaciones WebForms rápidas. Apostaría a que un desarrollador de ASP.NET senior podría producir una aplicación WebForms que compita con la velocidad de cualquier aplicación MVC, o al menos lograr una diferencia insignificante.

La verdadera diferencia, como sugirió @tvanfosson , está en la capacidad de prueba y el SoC limpio. Si mejorar el rendimiento es su principal preocupación, no creo que sea una buena razón para abandonar WebForms y comenzar a reconstruir en MVC. No al menos hasta que haya probado las técnicas disponibles para optimizar WebForms.

Disminuyó una de mis páginas de 2 MB de carga útil a 200k, simplemente eliminando el estado de visualización y haciéndolo soportable programáticamente para trabajar con la salida enviada.

El tamaño por sí solo, aunque el procesamiento fue el mismo, creará grandes mejoras en las conexiones por segundo y la velocidad de las solicitudes.

Creo que muchas de las personas que piensan que los WebForms son inherentemente lentos o que requieren muchos recursos, están echando la culpa al lugar equivocado. 9 de cada 10 veces, cuando me contratan para optimizar una aplicación de formularios web, hay demasiados lugares donde los autores de las aplicaciones malinterpretan el propósito del estado de visualización. No estoy diciendo que el estado de visualización sea perfecto ni nada, pero es MUY fácil abusar de él, y es este abuso el que está causando el campo de visualización inflado.

Este artículo fue invaluable para ayudarme a comprender muchos de estos abusos. https://weblogs.asp.net/infinitiesloop/truly-understanding-viewstate

Para hacer una comparación válida entre MVC y WebForms, debemos estar seguros de que ambas aplicaciones estén usando las arquitecturas correctamente.

Mi prueba muestra algo entre 2x y 7x más de solicitudes / seg en MVC, pero depende de cómo construya su aplicación de formularios web. Con solo el texto "hola mundo", sin ningún control del lado del servidor, mvc es entre un 30 y un 50% más rápido.

Para mí, la mejora real del "rendimiento" en MVC es el aumento de la superficie comprobable de la aplicación. Con WebForms, muchas de las aplicaciones eran difíciles de probar. Con MVC, la cantidad de código que se puede probar básicamente se duplica. Básicamente, todo lo que no se puede probar fácilmente es el código que genera el diseño. Toda su lógica empresarial y lógica de acceso a datos, incluida la lógica que completa los datos reales utilizados en la vista, ahora se puede probar. Si bien espero que también tenga más rendimiento (el ciclo de vida de la página se simplifica mucho y se adapta mejor a la programación web), incluso si fuera el mismo o un poco más lento, valdría la pena cambiarlo desde una perspectiva de calidad.

Creo que el problema aquí es que no importa cuánto más rápido sea ASP.Net MVC que los formularios web antiguos, no hará una diferencia, porque la mayor parte del tiempo que se toma es en la base de datos. La mayoría de las veces, sus servidores web estarán sentados en un 0-10% de uso de CPU 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.

Los únicos números concretos que puedo encontrar que son del desarrollo temprano de ASP.NET MVC están en este hilo del foro:

http://forums.asp.net/p/1231621/2224136.aspx

El propio Rob Connery confirma de alguna manera la declaración de que ScottGu ha afirmado que ASP.NET MVC puede atender 8000 solicitudes por segundo.

Quizás Jeff y su equipo puedan dar algún tipo de pista sobre el desarrollo de este sitio.

Contrariamente a la opinión aceptada, el uso optimizado de formularios web mata por completo a MVC en términos de rendimiento bruto. Webforms se ha hiperoptimizado para la tarea de servir html durante 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 las clasificaciones medio-bajo / bajo-alto de la lista, mientras que el uso de formularios web optimizados se ubica en las clasificaciones medio-alto / alto-bajo.

Una validación anecdótica pero muy seria de estas métricas, www.microsoft.com es servida por formularios web, no MVC. ¿Alguien aquí cree que no habría elegido MVC si fuera empíricamente más rápido?

Realmente no hay forma de responder a esto. MVC usa el motor de visualización de formularios Web Forms de forma predeterminada y se puede configurar para usar cualquier número de motores de visualización personalizados, por lo que si desea una comparación de rendimiento, tendrá que ser más específico.

Comencé a trabajar en MVC hace aproximadamente un año, estaba inspirado pero no impresionado.

Detesto el estado de la vista y lo veo como la raíz de todos los males en términos de ASP.NET. Es por eso que simplemente no lo uso y, para ser perfectamente honesto, ¿por qué lo harías tú?

Básicamente, tomé el concepto de ASP.NET MVC Framework y lo construí a mi manera. Sin embargo, cambié un par de cosas. Construí el código de envoltura de mi controlador o el código de enrutamiento de URL en torno a 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 según cómo las use. Si abandona por completo los WebForms, será más rápido porque el ciclo de vida de ASP.NET y el modelo de objetos son enormes.

Cuando escribes, estás creando una instancia de un ejército ... no, espera, una legión de objetos que participarán en la representación de tu vista. Esto será más lento que si expresara la cantidad mínima de comportamiento en la propia página ASPX. (No me importa la abstracción del motor de vista porque el soporte para páginas ASPX en Visual Studio es decente, pero he eliminado por completo WebForms como concepto y básicamente cualquier marco ASP.NET debido al exceso de código o al no poder cambiar el cosas que conectan mi solicitud).

Encontré formas de confiar en la recompilación dinámica (System.Reflection.Emit) para emitir códigos y objetos de propósito especial cuando sea necesario. La ejecución de este código es más rápida que la reflexión, pero inicialmente se construyó a través del servicio de reflexión. Esto le ha dado a mi framework con sabor a MVC un gran rendimiento pero también muy tipado estáticamente. No uso cadenas y colecciones de pares de nombre / valor. En cambio, mis servicios de compilador personalizados van en una reescritura de una publicación de formulario a una acción de controlador que se pasa un tipo de referencia. Detrás de la escena están sucediendo muchas cosas, 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 indican qué acción de controlador invocar. Esto no es particularmente rápido, pero es mejor que tener URL rotas. Es como si tuvieras recursos de tipo estático así como objetos de tipo estático. ¿Una aplicación web de tipo estático? ¡Eso es lo que quiero!

Animaría a más personas a probar esto.

Los proyectos creados con Visual Studio. Una es la plantilla mvc4, otra es WebForm (tradicional). Y cuando haga una 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 en servidores de 2 o 4 cpu

WebForms (aspx)

• podría superar las 2500 rps

• Se ha descubierto que el asesino del rendimiento es un error de MVC Bata o RC. Y el rendimiento mejorará una vez que elimine los paquetes. Ahora, la última versión solucionó esto.

El rendimiento depende de lo que esté haciendo ... Por lo general, MVC es más rápido que asp.net principalmente porque Viewstate está ausente y porque MVC funciona más con la devolución de llamada que con la devolución de datos de forma predeterminada.

Si optimiza la página de su formulario web, puede tener el mismo rendimiento que MVC, pero supondrá mucho trabajo.

Además, hay muchos nugets 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 un sprite, y así sucesivamente.

El rendimiento del sitio web depende en gran medida de su arquitectura. Uno limpio con una buena separación de preocupaciones le brindará 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 de forma predeterminada (consulte el sitio web MvcTemplate ).

Hice un pequeño experimento de prueba de carga VSTS con un código básico y descubrí que el tiempo de respuesta de ASP.NET MVC era dos veces más rápido en comparación con ASP.NET Webforms. Arriba está el gráfico adjunto con la trama.

Puede leer este experimento de prueba de carga en detalle en este artículo de CP https://www.codeproject.com/Articles/864950/ASP-NET-MVC-vs-ASP-NET-WebForm-performance-compari

La prueba se realizó con las siguientes especificaciones utilizando VSTS y el software de prueba de carga telerik: -

Carga de usuarios 25 usuarios.

La duración de la ejecución de la prueba fue de 10 minutos.

Configuración de la máquina DELL 8 GB de RAM, Core i3

El proyecto se alojó en IIS 8.

El proyecto fue creado usando MVC 5.

Se asumió una conexión de red LAN. Por lo tanto, esta prueba no tiene en cuenta el retraso de la red por ahora.

El navegador en la prueba seleccionó Chrome e Internet Explorer.

Se tomaron varias lecturas durante la prueba para promediar eventos desconocidos. Se tomaron 7 lecturas y todas las lecturas se publican en este artículo como lectura 1, 2 y así sucesivamente.