Ich fand einige wilde Bemerkungen, dass ASP.NET MVC ist 30x schneller als ASP.NET WebForms. Welchen wirklichen Leistungsunterschied gibt es, wurde das gemessen und was sind die Leistungsvorteile?ASP.NET MVC Leistung
Dies hilft mir, über den Wechsel von ASP.NET-WebForms zu ASP.NET MVC nachzudenken.
Wir haben nicht die Art von Skalierbarkeit und Perf-Tests durchgeführt, die notwendig sind, um irgendwelche Schlüsse zu ziehen. Ich denke, dass ScottGu potenzielle Perf-Ziele besprochen haben könnte. Auf dem Weg zu Beta und RTM werden wir intern mehr Leistungstests durchführen. Ich bin mir jedoch nicht sicher, was unsere Richtlinie für die Veröffentlichung von Ergebnissen von Perf-Tests ist.
In jedem Fall müssen solche Tests wirklich realen Anwendungen prüfen ...
Nun, da MVC veröffentlicht wurde, gibt es ein Update zur Veröffentlichung der Perf-Ergebnisse? – chris
Ich stimme nur, weil die 5.999 Rep-Punktzahl zuvor meinen Augen wehtat :( – Damien
Zu dieser Zeit müssen Sie sicherlich einige Nummern haben. Möchten Sie Ihre Antwort aktualisieren? Oder haben Sie festgestellt, dass die lästige Politik verbietet? – tvanfosson
Rick Strahl hat einige Gedanken über ASP.NET MVC-Leistung in What's Ailing ASP.NET Web Forms.
@Espo Danke. Ein sehr interessanter Artikel, obwohl er die Leistungsunterschiede zwischen den beiden nicht berührt. – GateKiller
Die einzigen konkreten Zahlen I, die sind von Anfang ASP.NET MVC-Entwicklung ist auf diesem Forum-Thread finden:
http://forums.asp.net/p/1231621/2224136.aspx
Rob Connery selbst bestätigt etwas Aussage, dass ScottGu dass ASP behauptet hat. NET MVC kann 8000 Anfragen pro Sekunde bedienen.
Vielleicht können Jeff und seine Crew einen Hinweis von ihrer Entwicklung dieser Seite geben.
Es verringert eine meiner Seiten von Nutzlast 2MB, auf 200k, nur durch den Ansichtszustand zu beseitigen und es erträglich programmatisch an die Arbeit machen mit der eingereichten Ausgabe.
Die Größe allein, obwohl die Verarbeitung die gleiche war, wird zu erheblichen Verbesserungen bei den Verbindungen pro Sekunde und der Geschwindigkeit der Anfragen führen.
Sie könnten diesen nervtötenden großen Viewstate auch ohne MVC behoben haben –
Nur um ViewState auszuarbeiten, kann @page level oder in web.config – bbqchickenrobot
ja ausgeschaltet werden, aber in mvc ist es ein vernünftiger Standard, keine Designentscheidung, die Sie zwingt, alle Steuerelemente zu verlassen die Anbieter, die vorgeben, nur an Webformularen zu arbeiten, indem sie Webformulare "falsch verhalten", indem sie ihren Rückgrat entfernen.Ich stimme dir nicht zu, du könntest diese Seite einfach neu kodieren, aber die ganze App war ohne Viewstate besser. – DevelopingChris
Es gibt wirklich keine Möglichkeit, dies zu beantworten. MVC verwendet die Web Forms-Ansichts-Engine standardmäßig selbst und kann für die Verwendung einer beliebigen Anzahl von benutzerdefinierten Ansichts-Engines konfiguriert werden. Wenn Sie also einen Leistungsvergleich durchführen möchten, müssen Sie genauer sein.
Meine Tests zeigen etwas zwischen 2x und 7x mehr req/sec auf MVC, aber es hängt davon ab, wie Sie Ihre Webforms App erstellen. Mit nur "Hallo Welt" Text, ohne jegliche Kontrolle auf der Serverseite, ist mvc etwa 30-50% schneller.
Für mich ist die wirkliche "Leistungsverbesserung" in 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 ist alles, was nicht leicht zu testen ist, der Code, der das Layout generiert. Alle Ihre Geschäftslogik und Datenzugriffslogik - einschließlich der Logik, die die tatsächlichen Daten in der Ansicht enthält - können jetzt getestet werden. Während ich erwarte, dass es auch leistungsfähiger ist - der Seitenlebenszyklus ist stark vereinfacht und der Webprogrammierung besser zugänglich - selbst wenn es gleich oder etwas langsamer wäre, wäre es wert, von einer Qualitätsperspektive zu wechseln.
Ich würde wirklich gerne wissen, warum jemand diese Antwort abgelehnt hat. – tvanfosson
Mein Gefühl ist, dass es downvoted werden könnte, weil eine gut gestaltete ASP.NET Web Forms-Anwendung genauso testbar wie eine MVC-Anwendung ist. Meine Erfahrung mit der Entwicklung von beiden ist, dass MVC Sie in ein sauberes Programmiermodell zwingt (was eine seiner größten Stärken ist, IMO). Mit Webformularen können Sie leichtere Dinge tun, aber es ist immer noch möglich, dieselbe testbare Oberfläche in Webformularen zu verwenden. Das ist meine Vermutung. – dudemonkey
Razor Ansichten ermutigen buchstäblich die Einbettung von Code in der Ansicht. Das ist nicht testbar, und es ist kein gutes Zeichen für die Trennung von Bedenken. Nur weil MVC Sie dazu bringt, Controller zu schreiben, heißt das nicht, dass Sie nicht alles auf den Kopf stellen können, wenn Sie nicht wissen, was Sie tun. Ein erfahrener Entwickler wird von WebForms (oder mehr) genauso viel Leistung bekommen wie MVC und wird eine praktisch identische "testbare Oberfläche" haben. –
Ich denke, dies ist eine schwierige Frage zu beantworten endgültig ist, wird auf A so viel abhängen), 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 Senior ASP.NET-Entwickler könnte eine WebForms-Anwendung erstellen, die mit der Geschwindigkeit einer MVC-Anwendung konkurriert - oder zumindest einen vernachlässigbaren Unterschied erzielt.
Der echte Unterschied - as @tvanfosson suggested - ist in Testbarkeit und sauberer SoC. Wenn es darum geht, die Leistung zu verbessern, ist das kein guter Grund, auf WebForms zu springen und mit dem Wiederaufbau in MVC zu beginnen. Nicht zuletzt, bis Sie die verfügbaren Techniken zum Optimieren von WebForms ausprobiert haben.
Große Antwort Todd (wie überraschend für einen Entwickler-Evangelisten, um tatsächlich eine pragmatische Antwort zu haben). Das einzige, was Sie falsch gemacht haben, ist in den rohen Implementierungen Webform ist in der Tat wesentlich schneller. –
Ich denke, dass viele der Leute, die denken, dass WebForms von Natur aus langsam oder ressourcenintensiv sind, die Schuld am falschen Ort platzieren. 9 von 10 Fällen, wenn ich zur Optimierung einer Webforms-App herangezogen werde, gibt es viel zu viele Orte, an denen die Apps-Autoren den Zweck des Viewstates missverstehen. 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 konnte mir nicht helfen, viele dieser Missbräuche zu verstehen. http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/truly-understanding-viewstate.aspx
Um einen gültigen Vergleich zwischen MVC und WebForms zu erstellen, müssen wir sicherstellen, dass beide Apps die Architekturen korrekt verwenden.
Ich begann vor einem Jahr in MVC zu arbeiten, ich war inspiriert, aber nicht beeindruckt.
Ich verabscheue den Ansichtszustand und sehe es als die Wurzel allen Übels in Bezug auf ASP.NET. Deshalb benutze ich es einfach nicht und um ehrlich zu sein, warum würdest du?
Ich nahm im Grunde das ASP.NET MVC Framework-Konzept und baute das auf meine eigene Art und Weise. Ich habe ein paar Dinge geändert. Ich habe meinen Controller-Wrapping-Code oder URL-Routing-Code um die dynamische Neukompilierung herum erstellt.
Jetzt würde ich gehen so weit zu sagen, dass ASP.NET MVC-Anwendungen werden schneller, je nachdem, wie Sie es verwenden. Wenn Sie WebForms vollständig aufgeben, sind Sie schneller, da das Lebenszyklus- und Objektmodell von ASP.NET enorm ist.
Wenn Sie schreiben, instanziieren Sie eine Armee ... nein, warten Sie, eine Legion von Objekten, die an der Wiedergabe Ihrer Ansicht teilnehmen. Das wird langsamer als wenn Sie das minimale Verhalten in der ASPX-Seite selbst ausdrücken möchten. (Ich interessiere mich nicht für View Engine Abstraktion, weil 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 aufgrund von Code Bloat oder nicht in der Lage, das zu ändern Dinge, die meine Anwendung verdrahten).
Ich habe Wege gefunden, sich auf die dynamische Neukompilierung (System.Reflection.Emit) zu verlassen, um spezielle Zweckobjekte und Code wann immer erforderlich zu senden. Die Ausführung dieses Codes ist schneller als die Reflektion, wird aber zunächst durch den Reflection-Service erstellt. Dies hat meinem MVC aromatisierten Framework eine großartige Leistung gegeben, aber auch sehr statisch getippt. Ich verwende keine Zeichenketten und Namen/Wert-Paar-Sammlungen. Stattdessen gehen meine benutzerdefinierten Compiler-Dienste in einen Formular-Post zu einer Controller-Aktion um, der ein Referenz-Typ übergeben wird. Hinter der Szene passiert eine Menge Dinge, aber dieser Code ist schnell, viel schneller als WebForms oder das MVC Framework.
Außerdem schreibe ich keine URLs, ich schreibe Lambda-Ausdrücke, die in URLs übersetzt werden, die später sagen, welche Controller-Aktion aufgerufen werden soll. Das ist nicht besonders schnell, aber es ist besser, wenn man URLs kaputt macht. Es ist, als hätten Sie sowohl statisch getippte Ressourcen als auch statisch typisierte Objekte. Eine statisch typisierte Webanwendung? Das ist was ich will!
Ich würde mehr Leute ermutigen, dies auszuprobieren.
Wie schnell fährt dein Auto? Nun, lass mich dir von meinem Truck erzählen, den ich gebaut habe ... – jfar
Das ist also keine direkte Antwort auf die Frage? Es ist jedoch verwandt, und es macht ein paar gute Punkte. Aber hey, es ist etwas, was ich für meine eigenen Bedürfnisse gebaut habe, und es steht mir vollkommen in Ordnung. Ich genieße es auch, meine Ideen zu teilen, auch wenn nur wenige Menschen verstehen, warum. –
Nun, es beantwortet die Frage nicht, Downvote bleibt. – jfar
Ich denke, das Problem hier ist, dass, egal wie viel schneller ASP.Net MVC ist als die alten Webforms, es wird keinen Unterschied machen, weil die meiste Zeit in der Datenbank genommen wird. Die meiste Zeit sitzen Ihre Webserver bei 0-10% CPU-Auslastung und warten nur auf Ihren Datenbankserver. Wenn Sie nicht extrem viele Zugriffe auf Ihre Website erhalten und Ihre Datenbank extrem schnell ist, werden Sie wahrscheinlich keinen großen Unterschied feststellen.
Ihre Benutzer könnten - kein Viewstate. – UpTheCreek
Here sind einige Zahlen von vor langer Zeit ...
Die Projekte mit Visual Studio erstellt. Einer ist mvc4-Vorlage, ein anderer ist WebForm (tranditional). Und wenn make load test mit WCAT, das ist das Ergebnis,
konnte über 2500 rps
die Performance Killer gefunden wurde erhalten, dass es ein Fehler von MVC Bata oder RC ist. Und die Leistung würde verbessert werden, sobald ich Bundles Sachen entferne. Jetzt hat die neueste Version das behoben.
Die Leistung hängt von was Sie tun ... In der Regel ist MVC schneller als asp.net vor allem, weil Viewstate fehlt und weil MVC arbeitet mehr mit Callback als Postback standardmäßig.
Wenn Sie Ihre Webformular-Seite optimieren, können Sie die gleiche Leistung wie MVC haben, aber es wird eine Menge Arbeit sein.
Auch ist es eine Menge Nugets für MVC (und auch für Webform), um Ihnen zu helfen, Website-Leistung zu verbessern wie css und javascripts zu kombinieren und zu minimieren, Ihre Bilder zu gruppieren und sie als Sprite zu verwenden.
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 Template" ansehen, die für Sie eine saubere Architektur mit vielen Leistungsverbesserungen standardmäßig erstellt (überprüfen Sie MvcTemplate Website).
Im Gegensatz zu der akzeptierten Meinung tötet eine optimierte Verwendung von Webforms MVC in Bezug auf die rohe Leistung vollständig ab. Webforms wurde für die Aufgabe, HTML viel länger als MVC anzubieten, hyperoptimiert.
Metrics sind auf http://www.techempower.com/benchmarks/#section=data-r7&hw=i7&test=db
Jeder einzelnen Vergleich mvc auf den unteren mittleren/unteren oberen Rankings der Liste ist, während optimiertem webforms Nutzung Plätze in den oberen Mitteln/Oben-Unten-Rankings.
Anekdotische, aber sehr ernsthafte Validierung zu diesen Metriken, www.microsoft.com wird von Webforms nicht MVC serviert. Glaubt irgendjemand hier, dass sie MVC nicht gewählt hätten, wenn es empirisch schneller wäre?
habe ich ein kleines VSTS Belastungstest Experiment mit einigen grundlegenden Code und gefunden zu ASP.NET Webforms verglichen zweimal schnellen ASP.NET MVC Antwortzeit zu sein. Oben ist das beigefügte Diagramm mit dem Diagramm.
Sie können diesen Belastungstest Experiment in Details von diesem CP Artikel http://www.codeproject.com/Articles/864950/ASP-NET-MVC-vs-ASP-NET-WebForm-performance-compari
-Test lesen mit den folgenden Spezifikationen durchgeführt wurde VSTS und telerik Lasttest-Software: -
Benutzerlast 25 Benutzer.
Laufzeit des Tests war 10 Minuten.
Maschine Config DELL 8 GB Ram, Core i3
Projekt wurde in IIS gehostet 8.
Projekt wurde mit MVC erstellt 5.
Netzwerk LAN-Verbindung angenommen wurde. Dieser Test berücksichtigt nun nicht die Netzwerkverzögerung.
Browser im Test ausgewählten Chrome und Internet Explorer.
Mehrere Messungen wurden während des Tests durchgeführt, um unbekannte Ereignisse zu mitteln. 7 Lesungen wurden gemacht und alle Lesungen sind in diesem Artikel als 1, 2 und so weiter veröffentlicht.
Ihre Testmethodik ist schlecht und stark verzerrt und Ihre Schlussfolgerungen sind ungültig. Eine ordnungsgemäß erstellte WebForms-Anwendung ist testbar, weist eine ordnungsgemäße Problemtrennung auf und weist einen minimalen Nutzlastaufwand auf. Während MVC keine Ereignisschleife für den Seitenlebenszyklus hat, muss es mit Routing und View-Ausführung konkurrieren. Ihre Artikel zu diesem Thema auf CP sind stark voreingenommen. –
Eine richtig und sorgfältig gebaute Anwendung selbst in der schlimmsten Technologie würde Wunder wirken. ASP.NET-Seitenlebenszyklus hat definitiv mehr Nutzlast im Vergleich zu Routing & View-Ausführung, da es sich um HTML-UI-Generierung handelt. Routing ist ein Teil von ASP.NET Framework, so dass sie auch in normalen Webformularen existieren. Eine Sache, der ich zustimme, wenn Sie Code hinter Ihrer Leistung nicht schreiben, wird MVC gleich sein. Aber Webform Toolbox ist so verlockend, dass Code dahinter ein wesentlicher Teil davon wird. Während MVC erlaubt mir das überhaupt nicht. Ich liebe, wie in Rasiermesser haben sie die Design-Ansicht und Code deaktiviert. –
Nachdem ich seit ihrer Veröffentlichung mit WebForms gearbeitet habe, werde ich nie wieder gerne zurückkehren! MVC hat meine <3 gestohlen - und diese Seite läuft super auf Beta 5! –
Was ist mit all den Revision Rollbacks zu dieser Frage ..? – Nick
@Nick: Das OP rückt alle Bearbeitungen zurück und löscht alle Kommentare, die sie erklären. – GEOCHET