Rendimiento de ASP.NET MVC
https://stackoverflow.com/questions/43743
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
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 existe? ¿Se ha medido? y ¿cuáles son los beneficios de rendimiento?
Esto es para ayudarme a considerar la posibilidad de pasar de ASP.NET WebForms a ASP.NET MVC.
Solución
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 avancemos 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 los resultados de las pruebas de rendimiento.
En cualquier caso, cualquier prueba de este tipo realmente debe considerar aplicaciones del mundo real...
Otros consejos
Creo que será una pregunta difícil de responder definitivamente, ya que mucho dependerá de A) cómo implementar la aplicación WebForms, y B) cómo se implementa la aplicación MVC.En sus formas "brutas", 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.Estaría dispuesto a apostar que un desarrollador senior de ASP.NET podría producir una aplicación WebForms que rivalice en velocidad con cualquier aplicación MVC, o al menos lograr una diferencia insignificante.
La verdadera diferencia- como sugirió @tvanfosson- está en capacidad de prueba y 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 una carga útil de 2 MB a 200 k, simplemente eliminando el estado de visualización y haciendo que fuera soportable programáticamente trabajar con la salida enviada.
El tamaño por sí solo, aunque el procesamiento sea 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 intrínsecamente lentos o consumen 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 la aplicación malinterpretan el propósito del estado de visualización.No estoy diciendo que el estado de vista sea perfecto ni nada por el estilo, pero es MUY fácil abusar de él, y es este abuso el que está causando el campo de estado de vista 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 asegurarnos de que ambas aplicaciones estén utilizando las arquitecturas correctamente.
Mis pruebas muestran algo entre 2 y 7 veces más solicitudes por segundo en MVC, pero depende de cómo construyas tu 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 verdadera mejora del "rendimiento" en MVC es el aumento de la superficie comprobable de la aplicación.Con WebForms había muchas aplicaciones que eran difíciles de probar.Con MVC, la cantidad de código que se puede probar básicamente se duplica.Básicamente, lo único que no se puede comprobar fácilmente es el código que genera el diseño.Toda su lógica de negocios 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 está enormemente simplificado y es más adaptable a la programación web), incluso si fuera igual 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 qué tan rápido sea ASP.Net MVC que los antiguos formularios web, no habrá diferencia, porque la mayor parte del tiempo que se toma está en la base de datos.La mayoría de las veces, sus servidores web estarán con un uso de CPU del 0 al 10% esperando en su servidor de base de datos.A menos que obtenga una gran cantidad de visitas a 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 pertenecen al desarrollo inicial de ASP.NET MVC se encuentran en este hilo del foro:
http://forums.asp.net/p/1231621/2224136.aspx
El propio Rob Connery confirma de alguna manera la afirmació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 acaba por completo con 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 media-baja/superior-baja de la lista, mientras que el uso de formularios web optimizados se ubica en las clasificaciones media-alta/baja-alta.
Validación anecdótica pero muy seria de estas métricas, www.microsoft.com es atendido por formularios web, no por MVC.¿Alguien aquí cree que no habrían elegido MVC si fuera empíricamente más rápido?
Realmente no hay manera de responder a esto.MVC utiliza el motor de visualización de Web Forms de forma predeterminada y se puede configurar para utilizar 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, me sentí inspirado pero no impresionado.
Detesto 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 yo simplemente no lo uso y, para ser honesto, ¿por qué lo harías tú?
Básicamente tomé el concepto de ASP.NET MVC Framework y lo construí a mi manera.Aunque cambié un par de cosas.Construí el código de ajuste de mi controlador o código de enrutamiento de URL en torno a la recompilación dinámica.
Ahora, me atrevería a decir que las aplicaciones ASP.NET MVC serán más rápidas según cómo las uses.Si abandona completamente WebForms, será más rápido porque el ciclo de vida y el modelo de objetos de ASP.NET 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 visualización porque el soporte para páginas ASPX en Visual Studio es decente, pero abandoné por completo los WebForms como concepto y básicamente cualquier marco ASP.NET debido a la sobrecarga del código o a no poder cambiar el cosas que conectan mi solicitud).
He encontrado 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 creó a través del servicio de reflexión.Esto le ha dado a mi marco con sabor MVC un gran rendimiento pero también un tipo muy estático.No uso cadenas ni colecciones de pares de nombre/valor.En cambio, mis servicios de compilador personalizados reescriben una publicación de formulario en una acción de controlador y se le pasa un tipo de referencia.Detrás de escena suceden 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 del controlador invocar.Esto no es particularmente rápido pero es mejor que tener URL rotas.Es como si tuviera recursos escritos estáticamente además de objetos escritos estáticamente.¿Una aplicación web escrita estáticamente?¡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 hacemos 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 tanto en servidores de 2 CPU como de 4 CPU
Formularios web (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ó este problema.
El rendimiento depende de lo que estés 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 Callback que con Postback de forma predeterminada.
Si optimiza su página de formulario web, puede tener el mismo rendimiento que MVC, pero requerirá mucho trabajo.
Además, hay muchas ventajas para MVC (y también para Webform) que le ayudarán a mejorar el rendimiento del sitio web, como combinar y minimizar su CSS y JavaScript, agrupar sus imágenes y usarlas como sprites, etc.
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.
Puedes echarle 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 Plantilla Mvc sitio web).
Hice un pequeño experimento de prueba de carga VSTS con algo de código básico y descubrí que el tiempo de respuesta de ASP.NET MVC es 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-rendimiento-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 Ram, Core i3
El proyecto se alojó en IIS 8.
El proyecto fue creado usando MVC 5.
Se asumió la 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 lecturas múltiples 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, etc.
