Performances ASP.NET MVC

Question

J'ai trouvé des remarques folles selon lesquelles ASP.NET MVC est 30 fois plus rapide que ASP.NET WebForms.Quelle est la réelle différence de performances, a-t-elle été mesurée et quels sont les avantages en termes de performances.

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

Answer 1

Nous n'avons pas effectué le type de tests d'évolutivité et de performances nécessaires pour tirer des conclusions.Je pense que ScottGu discutait peut-être d'objectifs de performances potentiels.À mesure que nous avançons vers la version bêta et RTM, nous effectuerons davantage de tests de performances en interne.Cependant, je ne suis pas sûr de quelle est notre politique en matière de publication des résultats des tests de performances.

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

Answer 2

Je pense qu'il sera difficile de répondre définitivement à cette question, car tout dépendra de UN) comment vous implémentez l'application WebForms, et B) comment implémenter l'application MVC.Dans leur forme « brute », MVC est probablement plus rapide que WebForms, mais des années et des années d'outils et d'expérience ont produit un certain nombre de techniques permettant de 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é- est en testabilité et SoC propre.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.

Answer 3

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

La taille à elle seule, même si le traitement était le même, créera de grandes améliorations en termes de connexions par seconde et de vitesse des requêtes.

Answer 4

Je pense que beaucoup de ceux qui pensent que les WebForms sont intrinsèquement lents ou gourmands en ressources rejettent la faute 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 de l'application comprennent mal le but de l'état d'affichage.Je ne dis pas que l'état d'affichage est parfait ou quoi que ce soit, mais il est BEAUCOUP trop facile d'en abuser, et c'est cet abus qui est à l'origine du champ d'état d'affichage gonflé.

Cet article m’a été d’une valeur 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.

Answer 5

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

Answer 6

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 pratiquement.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 votre logique d’accès aux données (y compris la logique qui alimente les données réelles utilisées dans la vue) peuvent désormais être testées.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 adapté à la programmation Web - même s'il était identique ou un peu plus lent, cela vaudrait la peine d'y passer du point de vue de la qualité.

Answer 7

Je pense que le problème ici est que peu importe à quel point ASP.Net MVC est plus rapide que les anciens formulaires Web, cela ne fera aucune différence, car la plupart du temps est passé dans la base de données.La plupart du temps, vos serveurs Web seront assis à une utilisation du processeur de 0 à 10 %, attendant simplement 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.

Answer 8

Les seuls chiffres concrets que je puisse trouver et qui proviennent des premiers développements d'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 8 000 requêtes par seconde.

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

Answer 9

Contrairement à l’opinion répandue, l’utilisation optimisée des formulaires Web tue complètement MVC en termes de performances brutes.Les formulaires Web ont été hyper-optimisés pour la tâche de servir du 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 le classement moyen inférieur/inférieur supérieur de la liste, tandis que l'utilisation optimisée des formulaires Web se situe dans le classement moyen supérieur/inférieur supé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.Est-ce que quelqu'un ici croit qu'il n'aurait pas choisi MVC s'il était empiriquement plus rapide ?

Answer 10

Il n'y a vraiment aucun moyen de répondre à cette question.MVC utilise lui-même le moteur d'affichage Web Forms par défaut 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.

Answer 11

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

Je déteste l'état d'affichage et le considère comme la racine de tous les maux 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 du framework ASP.NET MVC et je l'ai construit à ma manière.J'ai cependant changé quelques choses.J'ai construit mon code d'encapsulation de contrôleur ou mon 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 et le modèle objet ASP.NET 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 va être 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 correcte, mais j'ai complètement abandonné WebForms en tant que concept et essentiellement tout framework ASP.NET en raison d'une surcharge de code ou de l'impossibilité de modifier le les choses qui connectent ma candidature).

J'ai trouvé des moyens de m'appuyer sur la recompilation dynamique (System.Reflection.Emit) pour émettre des objets et du code spéciaux 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 à saveur MVC d'excellentes performances mais également un typage très statique.Je n'utilise pas de chaînes ni de collections de paires nom/valeur.Au lieu de cela, mes services de compilateur personnalisés réécrivent une publication de formulaire en une action de contrôleur recevant un type de référence.Dans les coulisses, il se passe beaucoup de choses, mais ce code est rapide, beaucoup plus rapide que WebForms ou le framework MVC.

De plus, je n'écris pas d'URL, j'écris des expressions lambda qui sont traduites en URL qui indiquent plus tard quelle action du contrôleur invoquer.Ce n'est pas particulièrement rapide, mais c'est mieux que d'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 typée statiquement ?C'est ce que je veux!

J'encouragerais davantage de personnes à essayer ceci.

Answer 12

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

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

MVC4

• je pourrais gagner environ 11 rps
• le rps est assez faible sur un serveur à 2 ou 4 processeurs

Formulaires Web (aspx)

• pourrait dépasser les 2500 rps

• le tueur de performances a été découvert qu'il s'agissait d'un bug de MVC Bata ou RC.Et les performances seraient améliorées une fois que je supprimerais les éléments Bundles.Maintenant, la dernière version a corrigé ce problème.

Answer 13

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 davantage avec le rappel qu'avec la publication par défaut.

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

En outre, il existe de nombreuses ressources pour MVC (et également pour Webform) pour vous aider à améliorer les performances de votre site Web, par exemple en combinant et en minimisant vos CSS et javascripts, en regroupant vos images et en les utilisant 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 manière d'améliorer les performances.

Vous pouvez jeter un œil à ce modèle "Modèle MVC Neos-SDI" qui créera pour vous une architecture propre avec de nombreuses améliorations de performances par défaut (cochez Modèle Mvc site web).

Answer 14

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 celui des 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 du CP https://www.codeproject.com/Articles/864950/ASP-NET-MVC-vs-ASP-NET-WebForm-performance-compari

Le test a été effectué 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 du test était de 10 minutes.

Configuration machine DELL 8 Go Ram, Core i3

Le projet a été hébergé dans IIS 8.

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

Une connexion réseau LAN a été supposée.Ce test ne prend donc pas en compte le décalage du réseau pour l'instant.

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

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