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?ASP.NET MVC Performance
Esto es para ayudarme a considerar pasar de ASP.NET WebForms a ASP.NET MVC.
No hemos realizado el tipo de escalabilidad y 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 todo caso, cualquiera de dichas pruebas realmente necesitan tener en cuenta las aplicaciones del mundo real ...
Ahora que se ha lanzado MVC, ¿hay alguna actualización sobre la publicación de los resultados de perf? – chris
Simplemente votando esto porque el puntaje de 5.999 repeticiones anterior me estaba lastimando :( – Damien
En este momento, seguramente debe tener algunos números. ¿Desea actualizar su respuesta? ¿O encontró que la política molesta lo prohíbe? – tvanfosson
Rick Strahl tiene algunas reflexiones sobre el rendimiento de ASP.NET MVC en What's Ailing ASP.NET Web Forms.
@Espo Gracias. Un artículo muy interesante, aunque no toca las diferencias de rendimiento entre los dos. – GateKiller
Los únicos números concretos que puedo encontrar que son desde principios de ASP.NET MVC-desarrollo es en este foro hilos: el propio
http://forums.asp.net/p/1231621/2224136.aspx
Rob Connery confirma algo declaración que ScottGu ha afirmado que ASP. NET MVC puede atender 8000 solicitudes por segundo.
Quizás Jeff y su tripulación puedan dar algún tipo de pista sobre el desarrollo de este sitio.
Disminuyó una de mis páginas de 2MB de carga útil, a 200k, simplemente eliminando el estado de vista y lo que es soportable mediante programación al trabajo 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.
podría haber arreglado ese gran viewstate molesto sin MVC también –
Solo para elaborar ViewState se puede apagar @ nivel de página o en web.config – bbqchickenrobot
sí, pero en mvc es un valor por defecto no una decisión de diseño que lo obliga a abandonar todos los controles y los proveedores que afirman simplemente trabajar en formularios web, al hacer que los formularios web "se porten mal" al eliminar su columna vertebral.No estoy en desacuerdo, podrías recodificar esa página, pero toda la aplicación era mejor sin viewstate. – DevelopingChris
Realmente no hay manera 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.
Mi prueba muestra 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.
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 me encantaría saber por qué alguien rechazó esta respuesta. – tvanfosson
Mi sensación es que podría ser downvoted porque una aplicación de formularios web ASP.NET bien diseñada es tan comprobable como una aplicación MVC. Mi experiencia con el desarrollo de ambos es que MVC te obliga a un modelo de programación limpio (que es uno de sus mayores puntos fuertes, IMO). Los formularios web le permiten hacer cosas más relajadas, pero aún es muy posible tener la misma superficie comprobable en los formularios web. Esa es mi suposición, de todos modos. – dudemonkey
Las vistas de la maquinilla de afeitar literalmente fomentan la incrustación de código dentro de la vista. Eso no es comprobable, y no es un buen augurio para la separación de preocupaciones. El hecho de que MVC te haga escribir controladores, no significa que no puedas ignorar todo si no sabes lo que estás haciendo. Un desarrollador experto obtendrá el mismo rendimiento de WebForms (o más) que MVC, y tendrá una "superficie comprobable" virtualmente idéntica. –
creo que esto será una cuestión difícil de responder definitivamente como mucho dependerá de A) cómo implementar la aplicación Web Forms, y B) modo en que 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. Estaría dispuesto a apostar que un ASP de alto rango.El desarrollador de 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- as @tvanfosson suggested - está en capacidad de prueba y 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.
Gran respuesta Todd (qué sorprendente para un desarrollador evangelista realmente tener una respuesta pragmática). Lo único que obtienes es que el formulario web de implementaciones sin procesar es mucho más rápido. –
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 al 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.
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 todos los males 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 usa. 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 instanciando 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 codificar 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 direcciones URL, escribo expresiones lambda que se traducen en URL que luego indican 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!
Animo a más personas a probar esto.
¿Qué tan rápido va tu automóvil? Bueno, déjame que te cuente sobre mi camión que construí ... – jfar
¿Entonces esta no es una respuesta directa a la pregunta? Sin embargo, está relacionado, y hace un par de buenos puntos. Pero bueno, es algo que construí para mis propias necesidades, y me sienta perfectamente bien. También disfruto compartir mis ideas, incluso si muy pocas personas entienden por qué. –
Bueno, no responde la pregunta, permanece downvote. – jfar
Creo que el problema aquí es que no importa cuánto más rápido sea ASP.Net MVC es 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.
Sus usuarios pueden - sin viewstate. – UpTheCreek
Here son algunas cifras de hace mucho tiempo ...
Los proyectos creados con Visual Studio. Una es la plantilla mvc4, otra es WebForm (tranditional). Y cuando realiza la prueba de carga con WCAT, este es el resultado,
podría obtener por encima de 2500 rps
el asesino rendimiento se ha encontrado que se trata de un error de MVC Bata o RC. Y el rendimiento se mejorará una vez que elimine las cosas de Bundles. Ahora la última versión solucionó esto.
El rendimiento depende de lo que está haciendo ... Por lo general, es más rápido que MVC asp.net sobre todo porque Viewstate está ausente y porque MVC trabaja más con devolución de llamada de devolución de datos por defecto.
Si optimiza su página web puede tener el mismo rendimiento que MVC, pero será un montón de trabajo.
Además, hay muchos complementos 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, 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 "Neos-SDI MVC Template" que creará para usted una arquitectura limpia con muchas mejoras de rendimiento por defecto (consulte el sitio web MvcTemplate).
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.
métricas están disponibles en http://www.techempower.com/benchmarks/#section=data-r7&hw=i7&test=db
Cada mvc comparación es en el ranking media-baja/inferior-superiores de la lista, mientras que los lugares de uso de formularios web optimizados en los rankings superiores de mediana/superior-inferior.
Una validación anecdótica pero muy seria para estas métricas, www.microsoft.com es proporcionada por webforms no MVC. ¿Alguien aquí cree que no habrían elegido MVC si fuera empíricamente más rápido?
lo hice un pequeño experimento de prueba de carga VSTS con algo de código básico y conocer el tiempo de respuesta ASP.NET MVC ser dos veces más rápido en comparación con ASP.NET formularios web. Arriba está el gráfico adjunto con la trama.
Usted puede leer este experimento prueba de carga en los detalles de este artículo CP http://www.codeproject.com/Articles/864950/ASP-NET-MVC-vs-ASP-NET-WebForm-performance-compari
prueba se realizó con las siguientes especificaciones utilizando VSTS y software de prueba de carga telerik: -
carga de usuarios 25 usuarios.
La duración de la prueba fue de 10 minutos.
Máquina config DELL 8 GB de RAM, Core i3
proyecto fue alojado en IIS 8.
proyecto fue creado usando MVC 5.
conexión de red LAN se suponía. 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.
Su metodología de prueba es mala, y muy parcial, y sus conclusiones no son válidas. Una aplicación WebForms correctamente construida es comprobable, tiene la separación adecuada de las preocupaciones y tiene una sobrecarga de carga mínima. Si bien MVC no tiene un ciclo de eventos de ciclo de vida de página, tiene que lidiar con el enrutamiento y la ejecución de la vista. Sus artículos sobre este tema en CP son muy parciales. –
Una aplicación correctamente y cuidadosamente construida incluso en la peor tecnología funcionaría milagros. El ciclo de vida de la página ASP.NET definitivamente tiene más carga útil en comparación con la ejecución de enrutamiento y vista, ya que trata con la generación de IU HTML. El enrutamiento forma parte del marco ASP.NET, por lo que incluso en los formularios web normales existen. Una cosa que acepto si no escribes código detrás de tu actuación será equivalente a MVC. Pero la caja de herramientas de Webform es tan tentadora que el código subyacente se convierte en una parte integral de él. Mientras que MVC no me permite hacer eso en absoluto. Me encanta cómo en la maquinilla de afeitar han desactivado la vista de diseño y el código. –
Después de trabajar con WebForms desde que salieron, ¡nunca volveré voluntariamente! MVC me ha robado mi <3 - ¡y este sitio funciona increíblemente en Beta 5! –
¿Qué pasa con todas las revisiones de revisión en esta pregunta ..? – Nick
@Nick: el OP está reduciendo cualquiera de las modificaciones y eliminando cualquier comentario que las explique. – GEOCHET