Nous n’avons pas effectué le type d’évolutivité et les tests de perf nécessaires pour tirer des conclusions. Je pense que ScottGu a peut-être discuté des cibles potentielles de perf. Au fur et à mesure que nous évoluons vers la bêta et la RTM, nous procéderons en interne à plus de tests de perf. Cependant, je ne suis pas sûr de notre politique en matière de publication des résultats des tests de perf.

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

Je pense que ce sera une question difficile à répondre définitivement car beaucoup 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 WebForms, mais des années et des années d’outils et d’expériences ont produit un certain nombre de techniques pour créer des applications WebForms rapides. Je suis prêt à parier qu’un développeur ASP.NET de haut niveau pourrait produire une application WebForms qui rivalise avec la vitesse de toute application MVC, ou du moins atteindre une différence négligeable.

La vraie différence, comme l’a suggéré @tvanfosson , est la testabilité et le SoC propre. Si l’amélioration de la performance est votre principale préoccupation, je ne pense pas que ce soit une bonne raison de sauter sur WebForms et de commencer à reconstruire dans MVC. Jusqu’à ce que vous ayez essayé les techniques disponibles pour optimiser WebForms.

Il a réduit une de mes pages de 2 Mo de charge utile à 200 Ko, simplement en éliminant le viewstate 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, entraînerait de grandes améliorations dans les connexions par seconde et la rapidité des requêtes.

Je pense que beaucoup de ceux qui pensent que les WebForms sont insortingnsèquement lents ou gourmands en ressources mettent le blâme au mauvais endroit. 9 fois sur 10, lorsque je suis amené à optimiser une application webforms, il y a beaucoup trop d’endroits où les auteurs d’applications ignorent l’object de la vue. Je ne dis pas que le viewstate est parfait ou quelque chose, mais il est trop facile d’en abuser, et c’est cet abus qui est à l’origine du champ de visualisation élevé.

Cet article m’a aidé à comprendre nombre de ces abus. http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/truly-understanding-viewstate.aspx

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

Mes tests montrent quelque chose entre 2x et 7x plus de req / sec sur MVC, mais cela dépend de la façon dont vous construisez votre application webforms. Avec juste du texte “Bonjour tout le monde”, sans aucun contrôle côté serveur, mvc est environ 30-50% plus rapide.

Rick Strahl a quelques reflections sur les performances de ASP.NET MVC dans What’s Ailing Web Forms ASP.NET .

Pour moi, l’amélioration réelle des performances de MVC est l’augmentation de la surface testable de l’application. Avec WebForms, une grande partie de l’application était difficile à tester. Avec MVC, la quantité de code qui devient testable double essentiellement. 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’access aux données, y compris la logique qui remplit les données réelles utilisées dans la vue, sont désormais susceptibles d’être testées. Bien que je m’attende à ce qu’il soit aussi plus performant – le cycle de vie des pages est grandement simplifié et plus adapté à la programmation Web – même s’il était identique ou un peu plus lent, il serait utile de passer d’un sharepoint vue qualitatif.

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 changera rien, car la plupart du temps, c’est dans la firebase database. La plupart du temps, les serveurs Web ne consumnt que 0 à 10% du temps d’utilisation de votre serveur de firebase database. À moins que vous n’obteniez un très grand nombre de visites sur votre site Web et que votre firebase database soit extrêmement rapide, vous ne remarquerez probablement pas de grande différence.

Les seuls chiffres concrets que je peux trouver qui proviennent des premiers développements ASP.NET MVC sont sur ce forum:

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

Rob Connery lui-même confirme quelque peu l’affirmation selon laquelle ScottGu a affirmé que ASP.NET MVC pouvait traiter 8 000 requêtes par seconde.

Peut-être que Jeff et son équipe pourront donner une idée de leur développement sur ce site.

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 diffusion de fichiers HTML beaucoup plus longtemps que MVC.

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

Chaque mvc de comparaison se situe dans le classement inférieur / moyen / supérieur de la liste, tandis que l’utilisation des formulaires Web optimisés se situe dans le classement moyen / supérieur / inférieur.

La validation anecdotique mais très sérieuse de ces mésortingques, http://www.microsoft.com est assurée par des formulaires Web et non par MVC. Est-ce que quelqu’un ici croit qu’ils n’auraient pas choisi MVC si c’était empiriquement plus rapide?

Il n’y a vraiment aucun moyen de répondre à cela. MVC utilise lui-même le moteur de vue Web Forms et peut être configuré pour utiliser un nombre quelconque de moteurs de vue personnalisés. Par conséquent, si vous souhaitez une comparaison des performances, vous devrez être plus spécifique.

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

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

J’ai pris essentiellement le concept ASP.NET MVC Framework et 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 dynamic.

J’irais jusqu’à dire que les applications ASP.NET MVC seront plus rapides en fonction de la manière dont vous les utilisez. Si vous abandonnez complètement WebForms, vous serez plus rapide car le cycle de vie et le modèle d’object ASP.NET sont énormes.

Lorsque vous écrivez, vous instanciez une armée … pas d’attente, une légion d’objects qui participeront au rendu de votre vue. Ce 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 de vue car le support des pages ASPX dans Visual Studio est décent, mais j’ai complètement abandonné WebForms en tant que concept et pratiquement tout framework ASP.NET en raison de la saturation de code). les choses qui connectent ma demande).

J’ai trouvé des moyens de compter sur la recompilation dynamic (System.Reflection.Emit) pour émettre des objects et du code à usage spécial lorsque cela est nécessaire. L’exécution de ce code est plus rapide que la reflection mais initialement construite à travers le service de reflection. Cela a donné à mon framework MVC une excellente performance mais aussi un typage très statique. 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 transmise à 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 invoquer. 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 objects typés statiquement. Une application web typée statiquement? C’est ce que je veux!

J’encouragerais plus de gens à l’essayer.

Les projets créés avec Visual Studio. L’un est le modèle mvc4, un autre est WebForm (tranditional). Et quand faire un test de charge avec WCAT, c’est le résultat,

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

MVC4

• pourrait obtenir environ 11 Rps
• RPS est assez faible à la fois serveur 2-CPU ou 4-CPU

Formulaires Web (aspx)

• pourrait dépasser 2500 Rps

• le tueur de performance a été trouvé que c’est un bug de MVC Bata ou de RC. Et la performance serait améliorée une fois que je supprime les choses Bundles. Maintenant, la dernière version a résolu ce problème.

Les performances dépendent de ce que vous faites … D’habitude, MVC est plus rapide que asp.net, principalement parce que Viewstate est absent et que MVC fonctionne davantage avec Callback que Postback par défaut.

Si vous optimisez votre page Webform, vous pouvez obtenir les mêmes performances que MVC, mais cela exigera beaucoup de travail.

De plus, il y a beaucoup de nugets pour MVC (et aussi pour Webform) pour vous aider à améliorer les performances du site, comme combiner et réduire vos css et javascripts, grouper vos images et les utiliser comme sprite, etc.

Les performances du site dépendent largement de votre architecture. Une solution propre avec une bonne séparation des préoccupations vous apportera un code plus clair et une meilleure idée de la manière dont vous améliorerez les performances.

Vous pouvez consulter 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 ).

Voici quelques chiffres d’il y a longtemps …

J’ai effectué une petite expérience de test de charge VSTS avec du code de base et j’ai trouvé que le temps de réponse ASP.NET MVC était deux fois plus rapide que celui des formulaires Web ASP.NET. Ci-dessus, le graphique ci-joint avec le tracé.

Vous pouvez lire cette expérience de test de charge en détail à partir de cet article du CP http://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 en utilisant le logiciel de test de charge VSTS et telerik: –

Charge utilisateur 25 utilisateurs.

La durée du test était de 10 minutes.

Config machine DELL 8 Go Ram, Core i3

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

Le projet a été créé avec MVC 5.

La connexion au réseau local 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.

Lectures multiples sockets lors du test pour évaluer les événements inconnus. 7 lectures sont sockets et toutes les lectures sont publiées dans cet article en lisant 1, 2 et ainsi de suite.