Performances ASP.NET MVC


102

J'ai trouvé quelques remarques farfelues selon lesquelles ASP.NET MVC est 30 fois plus rapide que ASP.NET WebForms. Quelle différence de performance réelle existe-t-il, cela a-t-il été mesuré et quels sont les avantages en termes de performances.

Cela m'aidera à envisager de passer de ASP.NET WebForms à ASP.NET MVC.


20
Après avoir travaillé avec WebForms depuis leur sortie, je n'y retournerai jamais volontiers! MVC a volé mon <3 - et ce site fonctionne à merveille sur la bêta 5!
Jarrod Dixon

2
Qu'est-ce que tous les annulations de révision sur cette question ..?
Nick

@Nick: L'OP annule toutes les modifications et supprime tous les commentaires les expliquant.
GEOCHET

@Rich B: Correct, il a supprimé environ 5 de mes commentaires.
George Stocker

2
Nécessite une mise à jour maintenant que nous approchons de la version MVC3.
Andrew Lewis

Réponses:


69

Nous n'avons pas effectué le type de tests d'évolutivité et de performances nécessaires pour tirer des conclusions. Je pense que ScottGu a peut-être discuté d'objectifs de performance potentiels. Au fur et à mesure que nous progressons vers la bêta et le RTM, nous effectuerons davantage de tests de performance en interne. Cependant, je ne suis pas sûr de notre politique en matière de publication des résultats des tests de performance.

Dans tous les cas, de tels tests doivent vraiment prendre en compte les applications du monde réel ...


13
Maintenant que MVC a été publié, y a-t-il une mise à jour sur la publication des résultats de perf?
chris

6
Je vote juste parce que le score de 5 999 représentants avant me faisait mal aux yeux :(
Damien

2
À ce stade, vous devez sûrement avoir des chiffres. Voulez-vous mettre à jour votre réponse? Ou avez-vous trouvé que la politique embêtante l'interdit?
tvanfosson

7
Le nombre est 42. :) En général, nos chiffres seront probablement inutiles pour les applications du monde réel, donc nous ne les donnons généralement pas. Cependant, je connais d'autres équipes de Microsoft qui construisent des sites Web à grande échelle qui affichent des chiffres favorables. En d'autres termes, tout problème de performance sera plus probablement dû à des erreurs de programmeur qu'à tout problème hérité du framework. Les interactions avec la base de données et les services externes sont généralement les coupables. :)
Haacked le

Vrai! Veuillez mettre à jour ceci! Peut-être pas des benchmarks mais une brève idée, sont-ils à la hauteur ou mvc est-il un tout petit peu meilleur sur les performances?
gideon

48

Je pense que ce sera une question difficile à répondre définitivement car tout dépendra de A) comment vous implémentez l'application WebForms, et B) comment vous implémentez l'application MVC. Dans leurs formes «brutes», MVC est probablement plus rapide que les WebForms, mais des années et des années d'outils et d'expérience ont produit un certain nombre de techniques pour créer des applications WebForms rapides. Je serais prêt à parier qu'un développeur ASP.NET senior pourrait produire une application WebForms qui rivalise avec la vitesse de n'importe quelle application MVC - ou au moins réaliser une différence négligeable.

La vraie différence - comme @tvanfosson l'a suggéré - réside dans la testabilité et la propreté du SoC. Si l'amélioration des performances est votre principale préoccupation, je ne pense pas que ce soit une bonne raison de quitter WebForms et de commencer à reconstruire dans MVC. Pas du moins jusqu'à ce que vous ayez essayé les techniques disponibles pour optimiser les WebForms.


Excellente réponse Todd (quelle surprise pour un développeur évangéliste d'avoir une réponse pragmatique). La seule chose que vous avez mal est que le formulaire Web des implémentations brutes est en effet beaucoup plus rapide.
Chris Marisic

42

Cela a réduit une de mes pages de 2 Mo de charge utile à 200 Ko, simplement en éliminant l'état d'affichage et en le rendant supportable par programme pour travailler avec la sortie soumise.

La taille seule, même si le traitement était le même, créera de vastes améliorations dans les connexions par seconde et la vitesse des requêtes.


31
vous auriez pu réparer cet état de vue grand et embêtant sans MVC aussi
Andrei Rînea

1
Juste pour élaborer ViewState peut être désactivé au niveau de la page ou dans web.config
bbqchickenrobot

8
oui mais dans mvc, c'est un défaut sensé, pas une décision de conception qui vous oblige à quitter tous les contrôles et les fournisseurs qui prétendent ne travailler que sur les formulaires Web, en rendant les formulaires Web "mal se comportent" en supprimant leur colonne vertébrale. Je ne conteste pas que vous puissiez simplement recoder cette page, mais toute l'application était meilleure sans viewstate.
DevelopingChris

alors ne pensez-vous pas que c'est la pire décision de votre part de porter l'ensemble de l'application vers MVC plutôt que de désactiver l'état d'affichage dans web.config? et non, viewstate n'est pas l'épine dorsale. seulement si vous avez effectué des recherches, viewstate peut être conservé dans le cache ainsi que dans les sessions.
Simple Fellow

29

Je pense que beaucoup de gens qui pensent que les WebForms sont intrinsèquement lents ou gourmands en ressources mettent le blâme au mauvais endroit. 9 fois sur 10, lorsque je suis amené à optimiser une application de formulaires Web, il y a beaucoup trop d'endroits où les auteurs d'applications comprennent mal le but de l'état d'affichage. Je ne dis pas que l'état de vue est parfait ou quoi que ce soit, mais il est BIEN trop facile d'en abuser, et c'est cet abus qui cause le champ de vue gonflé.

Cet article a été inestimable pour m'aider à comprendre bon nombre de ces abus. https://weblogs.asp.net/infinitiesloop/truly-understanding-viewstate

Afin de faire une comparaison valide entre MVC et WebForms, nous devons nous assurer que les deux applications utilisent correctement les architectures.


14

Mes tests montrent quelque chose entre 2x et 7x plus de req / s sur MVC, mais cela dépend de la manière dont vous créez votre application de formulaires Web. Avec juste du texte "bonjour le monde" dessus, sans aucun contrôle côté serveur, mvc est environ 30 à 50% plus rapide.


12

Pour moi, la véritable amélioration des "performances" dans MVC est l'augmentation de la surface testable de l'application. Avec WebForms, de nombreuses applications étaient difficiles à tester. Avec MVC, la quantité de code qui devient testable double fondamentalement. Fondamentalement, tout ce qui n'est pas facilement testable est le code qui génère la mise en page. Toute votre logique métier et logique d'accès aux données - y compris la logique qui remplit les données réelles utilisées dans la vue - peut désormais être testée. Même si je m'attends à ce qu'il soit également plus performant - le cycle de vie de la page est grandement simplifié et plus accessible à la programmation Web - même s'il était identique ou un peu plus lent, il serait intéressant de passer d'un point de vue de qualité.


J'aimerais vraiment savoir pourquoi quelqu'un a décliné cette réponse.
tvanfosson

Mon sentiment est qu'il pourrait être critiqué car une application de formulaires Web ASP.NET bien conçue est tout aussi testable qu'une application MVC. Mon expérience avec le développement des deux est que MVC vous force dans un modèle de programmation propre (qui est l'une de ses plus grandes forces, l'OMI). Les formulaires Web vous permettent de faire des choses plus paresseuses, mais il est toujours très possible d'avoir la même surface testable dans les formulaires Web. C'est ma supposition, de toute façon.
dudemonkey

Les vues Razor encouragent littéralement l'incorporation de code dans la vue. Ce n'est pas testable et cela n'augure rien de bon pour la séparation des préoccupations. Ce n'est pas parce que MVC vous oblige à écrire des contrôleurs que vous ne pouvez pas tout casser si vous ne savez pas ce que vous faites. Un développeur expérimenté obtiendra autant de performances de WebForms (ou plus) que MVC, et aura une "surface testable" pratiquement identique.
Richard Hauer

@RichardHauer ce n'était littéralement pas vrai quand j'ai écrit ceci, mais ils ont amélioré cela. Étant donné que WebForms ne semble pas avoir d'avenir dans .NET Core, cela semble être un point discutable.
tvanfosson le

@tvanfosson D'accord - c'est sans objet maintenant. Vous ne savez pas ce que vous pensez être faux, peut-être vous opposez-vous à mon utilisation de «littéralement»? Quoi qu'il en soit, les nouvelles versions de MVC avec TagHelpers aident à briser l'habitude de mettre du code dans des mises en page qui pourraient enfin faire fonctionner tout cela pour moi. J'apprécie que ce post soit assez ancien bien sûr, mais même à l'époque, un formulaire WebForms bien construit est très rapide sans le "câblage magique" de MVC et aucun code intégré dans la vue du tout.
Richard Hauer

7

Je pense que le problème ici est que peu importe à quel point ASP.Net MVC est beaucoup plus rapide que les anciens formulaires Web, cela ne fera aucune différence, car la plupart du temps est dans la base de données. La plupart du temps, vos serveurs Web seront assis à une utilisation du processeur de 0 à 10% juste en attente sur votre serveur de base de données. À moins que vous n'obteniez un très grand nombre de visites sur votre site Web et que votre base de données soit extrêmement rapide, vous ne remarquerez probablement pas une grande différence.


Vos utilisateurs pourraient - pas de viewstate.
UpTheCreek

6

Les seuls chiffres concrets que je peux trouver qui proviennent des premiers développements ASP.NET MVC se trouvent sur ce fil de discussion:

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

Rob Connery lui-même confirme quelque peu la déclaration selon laquelle ScottGu a affirmé qu'ASP.NET MVC peut traiter 8000 requêtes par seconde.

Peut-être que Jeff et son équipe peuvent donner une sorte d'indication sur le développement de ce site.


3

Contrairement à l'opinion acceptée, l'utilisation optimisée des formulaires Web tue complètement MVC en termes de performances brutes. Webforms a été hyper-optimisé pour la tâche de servir le HTML beaucoup plus longtemps que MVC.

Les métriques sont disponibles sur http://www.techempower.com/benchmarks/#section=data-r7&hw=i7&test=db

Chaque mvc de comparaison se trouve dans les classements inférieur-moyen / inférieur-supérieur de la liste, tandis que l'utilisation optimisée des formulaires Web se situe dans les classements supérieur-moyen / supérieur-inférieur.

Validation anecdotique mais très sérieuse de ces métriques, www.microsoft.com est servi par des formulaires Web et non par MVC. Quelqu'un ici pense-t-il qu'il n'aurait pas choisi MVC s'il avait été empiriquement plus rapide?


2

Il n'y a vraiment aucun moyen de répondre à cela. MVC utilise le moteur d'affichage Web Forms par défaut lui-même et peut être configuré pour utiliser n'importe quel nombre de moteurs d'affichage personnalisés.Par conséquent, si vous souhaitez une comparaison des performances, vous devrez être plus précis.


2

J'ai commencé à travailler chez MVC il y a environ un an, j'étais inspiré mais pas impressionné.

Je déteste l'état d'affichage et le considère comme la racine de tout mal en termes d'ASP.NET. C'est pourquoi je ne l'utilise tout simplement pas et pour être parfaitement honnête, pourquoi le feriez-vous?

J'ai essentiellement pris le concept ASP.NET MVC Framework et l'ai construit à ma manière. J'ai cependant changé deux ou trois choses. J'ai construit mon code de wrapping de contrôleur ou code de routage d'URL autour de la recompilation dynamique.

Maintenant, j'irais jusqu'à dire que les applications ASP.NET MVC seront plus rapides en fonction de la façon dont vous les utilisez. Si vous abandonnez complètement WebForms, vous serez plus rapide car le cycle de vie ASP.NET et le modèle objet sont énormes.

Lorsque vous écrivez vous instanciez une armée ... pas d'attente, une légion d'objets qui participeront au rendu de votre vue. Cela sera plus lent que si vous exprimiez le minimum de comportement dans la page ASPX elle-même. (Je ne me soucie pas de l'abstraction du moteur d'affichage car la prise en charge des pages ASPX dans Visual Studio est décente, mais j'ai complètement abandonné WebForms en tant que concept et fondamentalement tout framework ASP.NET en raison de la surcharge du code ou de l'impossibilité de modifier le choses qui filent ma candidature).

J'ai trouvé des moyens de s'appuyer sur la recompilation dynamique (System.Reflection.Emit) pour émettre des objets et du code à usage spécial chaque fois que nécessaire. L'exécution de ce code est plus rapide que la réflexion mais initialement construite via le service de réflexion. Cela a donné à mon framework MVC d'excellentes performances, mais aussi très typé statiquement. Je n'utilise pas de chaînes et de collections de paires nom / valeur. Au lieu de cela, mes services de compilateur personnalisés vont dans une réécriture d'une publication de formulaire à une action de contrôleur en passant un type de référence. Derrière la scène, il se passe beaucoup de choses mais ce code est rapide, beaucoup plus rapide que WebForms ou MVC Framework.

De plus, je n'écris pas d'URL, j'écris des expressions lambda qui sont traduites en URL qui indiquent plus tard quelle action de contrôleur appeler. Ce n'est pas particulièrement rapide, mais il vaut mieux avoir des URL cassées. C'est comme si vous aviez des ressources typées statiquement ainsi que des objets typés statiquement. Une application Web de type statique? C'est ce que je veux!

J'encouragerais plus de gens à essayer ceci.


2
Ce n'est donc pas une réponse directe à la question? C'est cependant lié, et cela fait quelques bons points. Mais bon, c'est quelque chose que j'ai construit pour mes propres besoins, et cela me convient parfaitement. J'aime aussi partager mes idées, même si très peu de gens comprennent pourquoi.
John Leidegren

1
Eh bien, vous n'êtes pas obligé de modifier votre vote, mais vous n'êtes pas obligé de voter contre, car ce n'est pas «la» réponse. Si vous examinez le texte pendant un moment, plusieurs éléments indiquent que ASP.NET MVC est plus rapide que WebForms et pourquoi c'est le cas. Et cela se résume à des choses comme la réflexion et le modèle d'objet et la surcharge ViewState des WebForms.
John Leidegren

@John - maintenant que MVC2 est sorti avec une liaison de modèle améliorée, une validation, des helpers fortement typés, etc., comment l'évaluer par rapport à votre méthode?
tvanfosson

MVC2 est bien meilleur, je pense qu'il a pratiquement remplacé ce que je construisais à l'époque (avec MVC1 en version bêta). Je suis tombé sur une véritable épreuve de problèmes par rapport à ce que j'essayais de construire sur ASP.NET sans désactiver les outils existants. Il suffit de dire que j'ai beaucoup appris et finalement mis cela en production. Je me rends compte maintenant que les outils / frameworks actuels (VS / ASP.NET / C #) ne sont pas vraiment adaptés à ce genre de choses et finalement si vous voulez vous engager dans cette voie, vous devrez investir dans vos propres compilateurs / vérifications de modèles trucs pour que certaines choses fonctionnent en votre faveur.
John Leidegren

Je ne pensais pas beaucoup à ASP.NET MVC à cette époque. Il manquait des choses que je savais que je voulais. Mais j'ai dû passer beaucoup de temps à développer, tester et comprendre ces choses. Je pense toujours que l'aspect statique du framework Web que je construisais est supérieur à MVC à cet égard, mais le compilateur C # est inefficace pour résoudre ce problème. Vous avez besoin d'un langage / compilateur qui permet une plus grande flexibilité en matière de métaprogrammation. J'ai dû faire beaucoup de cela au moment de l'exécution et il était souvent impossible de mettre en cache les instances compilées, donc j'ai dû beaucoup recompiler dynamiquement les choses.
John Leidegren

2

Les projets créés avec Visual Studio. L'un est le modèle mvc4, un autre est WebForm (tranditional). Et lorsque vous effectuez un test de charge avec WCAT, voici le résultat,

MVC4 est assez lent que WebForms, des idées?

entrez la description de l'image ici

MVC4

  • pourrait obtenir environ 11 rps
  • rps est assez faible à la fois serveur 2 cpu ou 4 cpu

entrez la description de l'image ici

WebForms (aspx)

  • pourrait dépasser 2500 rps

  • le tueur de performances a été trouvé que c'est un bogue de MVC Bata ou RC. Et les performances seraient améliorées une fois que je supprimerais les éléments de Bundles. Maintenant, la dernière version a corrigé ce problème.


1

Les performances dépendent de ce que vous faites ... Habituellement, MVC est plus rapide que asp.net principalement parce que Viewstate est absent et parce que MVC fonctionne plus avec Callback qu'avec Postback par défaut.

Si vous optimisez votre page de formulaire Web, vous pouvez avoir les mêmes performances que MVC, mais ce sera beaucoup de travail.

En outre, il y a beaucoup de pépites pour MVC (et aussi pour Webform) pour vous aider à améliorer les performances du site Web, comme combiner et réduire votre css et vos javascripts, regrouper vos images et les utiliser comme sprite, etc.

Les performances du site Web dépendent grandement de votre architecture. Un code propre avec une bonne séparation des préoccupations vous apportera un code plus propre et une meilleure idée de la façon d'améliorer les performances.

Vous pouvez jeter un oeil à ce modèle " Neos-SDI MVC Template " qui créera pour vous une architecture propre avec de nombreuses améliorations de performances par défaut (consultez le site Web MvcTemplate ).


-1

entrez la description de l'image ici

J'ai fait une petite expérience de test de charge VSTS avec du code de base et j'ai trouvé que le temps de réponse d'ASP.NET MVC était deux fois plus rapide que les formulaires Web ASP.NET. Ci-dessus se trouve le graphique ci-joint avec le tracé.

Vous pouvez lire cette expérience de test de charge en détail dans cet article CP https://www.codeproject.com/Articles/864950/ASP-NET-MVC-vs-ASP-NET-WebForm-performance-compari

Le test a été réalisé avec les spécifications ci-dessous à l'aide du logiciel de test de charge VSTS et telerik: -

L'utilisateur charge 25 utilisateurs.

La durée de l'essai était de 10 minutes.

Configuration de la machine DELL 8 Go Ram, Core i3

Le projet était hébergé dans IIS 8.

Le projet a été créé à l'aide de MVC 5.

La connexion réseau LAN a été supposée. Donc, ce test ne tient pas compte du retard du réseau pour le moment.

Navigateur dans le test sélectionné Chrome et Internet Explorer.

Plusieurs lectures ont été effectuées pendant le test pour faire la moyenne d'événements inconnus. 7 lectures où prises et toutes les lectures sont publiées dans cet article comme lecture 1, 2 et ainsi de suite.


Votre méthodologie de test est mauvaise et fortement biaisée, et vos conclusions sont invalides. Une application WebForms correctement construite peut être testée, a une séparation appropriée des préoccupations et a une charge utile minimale. Bien que MVC n'ait pas de boucle d'événement de cycle de vie de page, il doit gérer le routage et l'exécution des vues. Vos articles sur ce sujet sur le CP sont fortement biaisés.
Richard Hauer

Une application correctement et soigneusement construite, même dans la pire des technologies, ferait des miracles. Le cycle de vie de la page ASP.NET a certainement plus de charge utile par rapport à l'exécution du routage et de la vue, car il traite de la génération d'interface utilisateur HTML. Le routage fait partie du framework ASP.NET, donc même dans les formulaires Web normaux, ils existent. Une chose que je suis d'accord si vous n'écrivez pas de code derrière vos performances sera équivalente à MVC, mais la boîte à outils Webform est si tentante que le code derrière en fait partie intégrante. Bien que MVC ne me permette pas du tout de faire cela. J'adore la façon dont Razor a désactivé la vue de conception et le code derrière.
Shivprasad Koirala le
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.