Ich habe einige wilde Bemerkungen gefunden, dass ASP.NET MVC 30x schneller ist als ASP.NET WebForms. Welcher tatsächliche Leistungsunterschied besteht, wurde gemessen und welche Leistungsvorteile gibt es?

Dies soll mir helfen, den Wechsel von ASP.NET WebForms zu ASP.NET MVC in Betracht zu ziehen.

Wir haben nicht die Art von Skalierbarkeits- und Perfektionstests durchgeführt, die erforderlich sind, um Schlussfolgerungen zu ziehen. Ich denke, ScottGu hat möglicherweise über mögliche Leistungsziele gesprochen. Auf dem Weg zu Beta und RTM werden wir intern mehr Perf-Tests durchführen. Ich bin mir jedoch nicht sicher, wie wir die Ergebnisse von Perf-Tests veröffentlichen.

In jedem Fall müssen solche Tests wirklich reale Anwendungen berücksichtigen ...

Ich denke, dies wird eine schwer zu beantwortende Frage sein, da so viel davon abhängt, A) wie Sie die WebForms-Anwendung implementieren und B) wie Sie die MVC-Anwendung implementieren. In ihren "rohen" Formen ist MVC wahrscheinlich schneller als WebForms, aber jahrelange Tools und Erfahrungen haben eine Reihe von Techniken zum Erstellen schneller WebForms-Anwendungen hervorgebracht. Ich würde wetten, dass ein erfahrener ASP.NET-Entwickler eine WebForms-Anwendung erstellen könnte, die mit der Geschwindigkeit einer MVC-Anwendung mithalten kann - oder zumindest einen vernachlässigbaren Unterschied erzielt.

Der wirkliche Unterschied - wie @tvanfosson vorgeschlagen hat - liegt in der Testbarkeit und dem sauberen SoC. Wenn die Verbesserung der Leistung Ihr Hauptanliegen ist, ist dies meines Erachtens kein guter Grund, auf WebForms umzusteigen und mit dem Wiederaufbau in MVC zu beginnen. Nicht zuletzt, bis Sie die verfügbaren Techniken zur Optimierung von WebForms ausprobiert haben.

Es hat eine meiner Seiten von 2 MB Nutzlast auf 200 KB reduziert, indem nur der Ansichtsstatus entfernt und es programmierbar gemacht wurde, mit der übermittelten Ausgabe zu arbeiten.

Die Größe allein, obwohl die Verarbeitung gleich war, führt zu enormen Verbesserungen der Verbindungen pro Sekunde und der Geschwindigkeit der Anforderungen.

Ich denke, dass viele der Leute, die denken, dass WebForms von Natur aus langsam oder ressourcenintensiv sind, die Schuld an der falschen Stelle platzieren. 9 von 10 Fällen, in denen ich zur Optimierung einer Webforms-App hinzugezogen werde, gibt es viel zu viele Stellen, an denen die Autoren der Apps den Zweck des Ansichtsstatus falsch verstehen. Ich sage nicht, dass der Viewstate perfekt ist oder so, aber es ist viel zu einfach, ihn zu missbrauchen, und es ist dieser Missbrauch, der das aufgeblähte Viewstate-Feld verursacht.

Dieser Artikel war von unschätzbarem Wert, um mir zu helfen, viele dieser Missbräuche zu verstehen. https://weblogs.asp.net/infinitiesloop/truly-understanding-viewstate

Um einen gültigen Vergleich zwischen MVC und WebForms durchführen zu können, müssen wir sicherstellen, dass beide Apps die Architekturen korrekt verwenden.

Meine Tests zeigen, dass MVC zwischen 2x und 7x mehr Anforderungen / Sek. Erhält, aber es hängt davon ab, wie Sie Ihre Webforms-App erstellen. Mit nur "Hallo Welt" -Text ohne serverseitige Steuerung ist mvc etwa 30-50% schneller.

Für mich ist die eigentliche "Leistungsverbesserung" bei MVC die Erhöhung der testbaren Oberfläche der Anwendung. Mit WebForms gab es viele Anwendungen, die schwer zu testen waren. Mit MVC verdoppelt sich die Menge an Code, die testbar wird, im Grunde. Grundsätzlich ist der Code, der das Layout generiert, nicht einfach zu testen. Ihre gesamte Geschäftslogik und Datenzugriffslogik - einschließlich der Logik, die die in der Ansicht tatsächlich verwendeten Daten auffüllt - kann jetzt getestet werden. Ich erwarte zwar, dass es auch leistungsfähiger ist - der Seitenlebenszyklus ist erheblich vereinfacht und für die Webprogrammierung zugänglicher -, selbst wenn es gleich oder etwas langsamer wäre, lohnt es sich, aus Sicht der Qualität zu wechseln.

Ich denke, das Problem hier ist, dass ASP.Net MVC, egal wie viel schneller es ist als die alten Webformulare, keinen Unterschied macht, da die meiste Zeit in der Datenbank verbracht wird. Die meiste Zeit sitzen Ihre Webserver mit 0-10% CPU-Auslastung und warten nur auf Ihren Datenbankserver. Wenn Sie nicht eine extrem große Anzahl von Treffern auf Ihrer Website erhalten und Ihre Datenbank extrem schnell ist, werden Sie wahrscheinlich keinen großen Unterschied bemerken.

Die einzigen konkreten Zahlen, die ich aus der frühen ASP.NET MVC-Entwicklung finden kann, befinden sich in diesem Forum-Thread:

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

Rob Connery selbst bestätigt etwas die Aussage, dass ScottGu behauptet hat, dass ASP.NET MVC 8000 Anfragen pro Sekunde bedienen kann.

Vielleicht können Jeff und seine Crew einen Hinweis auf ihre Entwicklung dieser Seite geben.

Entgegen der akzeptierten Meinung wird MVC durch die optimierte Nutzung von Webformularen in Bezug auf die Rohleistung vollständig beeinträchtigt. Webforms wurde für die Aufgabe optimiert, HTML viel länger als MVC bereitzustellen.

Metriken finden Sie unter http://www.techempower.com/benchmarks/#section=data-r7&hw=i7&test=db

Jeder einzelne Vergleich mvc befindet sich in den unteren, mittleren und unteren oberen Rängen der Liste, während optimierte Webformulare in den oberen, mittleren und oberen unteren Rängen platziert werden.

Anekdotisch , aber sehr schwere Validierung dieser Metriken, www.microsoft.com wird von Webforms nicht MVC serviert. Glaubt hier jemand, dass er MVC nicht gewählt hätte, wenn es empirisch schneller gewesen wäre?

Es gibt wirklich keine Möglichkeit, dies zu beantworten. MVC verwendet standardmäßig das Web Forms-Ansichtsmodul selbst und kann so konfiguriert werden, dass eine beliebige Anzahl von benutzerdefinierten Ansichtsmodulen verwendet wird. Wenn Sie also einen Leistungsvergleich wünschen, müssen Sie spezifischer sein.

Ich habe vor ungefähr einem Jahr bei MVC angefangen, war begeistert, aber nicht beeindruckt.

Ich hasse den Ansichtsstatus und sehe ihn als die Wurzel allen Übels in Bezug auf ASP.NET. Deshalb benutze ich es einfach nicht und um ganz ehrlich zu sein, warum sollten Sie?

Ich habe im Grunde das ASP.NET MVC Framework-Konzept übernommen und es auf meine eigene Weise erstellt. Ich habe jedoch ein paar Dinge geändert. Ich habe meinen Controller-Wrapping-Code oder URL-Routing-Code um die dynamische Neukompilierung herum erstellt.

Nun würde ich sogar sagen, dass ASP.NET MVC-Anwendungen je nach Verwendung schneller sind. Wenn Sie WebForms vollständig verlassen, sind Sie schneller, da der ASP.NET-Lebenszyklus und das Objektmodell sehr umfangreich sind.

Wenn Sie schreiben, instanziieren Sie eine Armee ... keine Wartezeit, eine Legion von Objekten, die an der Wiedergabe Ihrer Ansicht beteiligt sind. Dies wird langsamer sein, als wenn Sie das minimale Verhalten auf der ASPX-Seite selbst ausdrücken möchten. (Die Abstraktion der View Engine ist mir egal, da die Unterstützung für ASPX-Seiten in Visual Studio anständig ist, aber ich habe WebForms als Konzept und im Grunde jedes ASP.NET-Framework vollständig verworfen, weil der Code aufgebläht ist oder das nicht geändert werden kann Dinge, die meine Bewerbung verkabeln).

Ich habe Möglichkeiten gefunden, mich auf die dynamische Neukompilierung (System.Reflection.Emit) zu verlassen, um bei Bedarf spezielle Objekte und Code auszugeben. Die Ausführung dieses Codes ist schneller als die Reflexion, wird jedoch zunächst über den Reflexionsdienst erstellt. Dies hat meinem MVC-aromatisierten Framework eine großartige Leistung verliehen, aber auch eine sehr statische Typisierung. Ich verwende keine Zeichenfolgen und Namens- / Wertepaar-Sammlungen. Stattdessen schreiben meine benutzerdefinierten Compilerdienste einen Formularbeitrag in eine Controller-Aktion, der ein Referenztyp übergeben wird. Hinter den Kulissen ist viel los, aber dieser Code ist schnell, viel schneller als WebForms oder das MVC Framework.

Außerdem schreibe ich keine URLs, sondern Lambda-Ausdrücke, die in URLs übersetzt werden, die später angeben, welche Controller-Aktion aufgerufen werden soll. Dies ist nicht besonders schnell, aber es ist besser als defekte URLs. Es ist, als hätten Sie sowohl statisch typisierte Ressourcen als auch statisch typisierte Objekte. Eine statisch typisierte Webanwendung? Das ist was ich will!

Ich würde mehr Leute ermutigen, dies auszuprobieren.

Die mit Visual Studio erstellten Projekte. Eine ist eine mvc4-Vorlage, eine andere ist WebForm (tranditional). Und wenn Sie einen Lasttest mit WCAT durchführen, ist dies das Ergebnis:

MVC4 ist ziemlich langsam als WebForms, irgendwelche Ideen?

MVC4

• könnte etwa 11 U / min bekommen
• rps ist sowohl bei 2-CPU- als auch bei 4-CPU-Servern ziemlich niedrig

WebForms (aspx)

• könnte über 2500 U / min bekommen

• Der Performance-Killer hat festgestellt, dass es sich um einen Fehler von MVC Bata oder RC handelt. Und die Leistung würde verbessert, wenn ich Bundles Dinge entferne. Jetzt hat die neueste Version dies behoben.

Die Leistung hängt davon ab, was Sie tun ... Normalerweise ist MVC schneller als asp.net, hauptsächlich weil Viewstate fehlt und MVC standardmäßig mehr mit Callback als mit Postback arbeitet.

Wenn Sie Ihre Webform-Seite optimieren, können Sie die gleiche Leistung wie bei MVC erzielen, dies ist jedoch eine Menge Arbeit.

Außerdem gibt es viele Nugets für MVC (und auch für Webform), mit denen Sie die Leistung Ihrer Website verbessern können, z. B. CSS und Javascripts kombinieren und minimieren, Ihre Bilder gruppieren und als Sprite verwenden usw.

Die Leistung der Website hängt stark von Ihrer Architektur ab. Ein sauberer Code mit einer guten Trennung der Bedenken bringt Ihnen einen saubereren Code und eine bessere Vorstellung davon, wie Sie die Leistung verbessern können.

Sie können sich diese Vorlage " Neos-SDI MVC-Vorlage " ansehen, die standardmäßig eine saubere Architektur mit vielen Leistungsverbesserungen für Sie erstellt (überprüfen Sie MvcTemplate) Website).

Ich habe ein kleines VSTS-Lasttest-Experiment mit grundlegendem Code durchgeführt und festgestellt, dass die Antwortzeit von ASP.NET MVC im Vergleich zu ASP.NET Webforms doppelt so schnell ist. Oben ist das angehängte Diagramm mit dem Diagramm.

Sie können dieses Belastungstest-Experiment ausführlich in diesem CP-Artikel https://www.codeproject.com/Articles/864950/ASP-NET-MVC-vs-ASP-NET-WebForm-performance-compari lesen

Der Test wurde mit den folgenden Spezifikationen unter Verwendung von VSTS- und Telerik-Lasttest-Software durchgeführt: -

Benutzer laden 25 Benutzer.

Die Testdauer betrug 10 Minuten.

Maschinenkonfiguration DELL 8 GB RAM, Core i3

Das Projekt wurde in IIS 8 gehostet.

Das Projekt wurde mit MVC 5 erstellt.

Es wurde eine Netzwerk-LAN-Verbindung angenommen. Dieser Test berücksichtigt also vorerst keine Netzwerkverzögerung.

Browser im Test ausgewählt Chrome und Internet Explorer.

Während des Tests wurden mehrere Messungen durchgeführt, um unbekannte Ereignisse zu mitteln. Es wurden 7 Lesungen vorgenommen und alle Lesungen werden in diesem Artikel als Lesung 1, 2 usw. veröffentlicht.