Ik vond enkele wilde opmerkingen dat ASP.NET MVC 30x sneller is dan ASP.NET WebForms. Welk echt prestatieverschil is er, is dit gemeten en wat zijn de prestatievoordelen.

Dit is om me te helpen overwegen over te stappen van ASP.NET WebForms naar ASP.NET MVC.

Antwoord 1, autoriteit 100%

We hebben niet het type schaalbaarheids- en prestatietests uitgevoerd dat nodig is om conclusies te trekken. Ik denk dat ScottGu mogelijke perf-doelen heeft besproken. Naarmate we richting Beta en RTM gaan, zullen we intern meer perf-testen doen. Ik weet echter niet zeker wat ons beleid is met betrekking tot het publiceren van resultaten van prestatietests.

In elk geval moeten dergelijke tests echt rekening houden met toepassingen in de echte wereld…

Antwoord 2, autoriteit 70%

Ik denk dat dit een moeilijke vraag zal zijn om definitief te beantwoorden, omdat zoveel zal afhangen van A)hoe u de WebForms-toepassing implementeert, en B)hoe u de MVC-applicatie. In hun “onbewerkte” vormen is MVC waarschijnlijk sneller dan WebForms, maar jaren en jaren van tools en ervaring hebben een aantal technieken voortgebracht voor het bouwen van snelle WebForms-applicaties. Ik durf te wedden dat een senior ASP.NET-ontwikkelaar een WebForms-toepassing kan maken die even snel kan zijn als elke MVC-toepassing, of op zijn minst een verwaarloosbaar verschil kan bereiken.

Het echte verschil – zoals @tvanfosson suggereerde– zit in de testbaarheid en schone SoC. Als het verbeteren van de prestaties je grootste zorg is, denk ik niet dat het een goede reden is om over te stappen op WebForms en opnieuw te beginnen in MVC. Niet in ieder geval totdat je de beschikbare technieken voor het optimaliseren van WebForms hebt uitgeprobeerd.

Antwoord 3, autoriteit 61%

Het verminderde een van mijn pagina’s van 2 MB laadvermogen naar 200k, gewoon door de weergavestatus te elimineren en het programmatisch draaglijk te maken om met de ingediende uitvoer te werken.

Alleen de grootte, hoewel de verwerking hetzelfde was, zal enorme verbeteringen opleveren in verbindingen per seconde en snelheid van de verzoeken.

Antwoord 4, autoriteit 42%

Ik denk dat veel van de mensen die denken dat WebForms inherent traag zijn of veel middelen nodig hebben, de schuld op de verkeerde plaats leggen. 9 van de 10 keer als ik word ingeschakeld om een ​​app voor webformulieren te optimaliseren, zijn er veel te veel plaatsen waar de auteurs van apps het doel van de weergavestatus verkeerd begrijpen. Ik zeg niet dat de weergavestatus perfect is of zo, maar het is VEEL te gemakkelijk om er misbruik van te maken, en het is dit misbruik dat de opgeblazen weergavestatus veroorzaakt.

Dit artikel was van onschatbare waarde om me te helpen veel van deze misbruiken te begrijpen. https://weblogs.asp.net/infinitiesloop/truly-understanding-viewstate

Om een ​​geldige vergelijking tussen MVC en WebForms te kunnen maken, moeten we er zeker van zijn dat beide apps de architecturen correct gebruiken.

Antwoord 5, autoriteit 20%

Mijn testen tonen iets tussen 2x en 7x meer req/sec op MVC, maar het hangt ervan af hoe je je webformulieren-app bouwt. Met alleen “hello world” tekst erop, zonder enige controle aan de serverzijde, is mvc ongeveer 30-50% sneller.

Antwoord 6, autoriteit 17%

Voor mij is de echte “prestatie”-verbetering in MVC de toename van het testbare oppervlak van de applicatie. Met WebForms was er veel van de applicatie die moeilijk te testen was. Met MVC verdubbelt de hoeveelheid code die testbaar wordt in principe. Eigenlijk is het enige dat niet gemakkelijk te testen is de code die de lay-out genereert. Al uw bedrijfslogica en gegevenstoegangslogica – inclusief de logica die de daadwerkelijke gegevens vult die in de weergave worden gebruikt – kan nu worden getest. Hoewel ik verwacht dat het ook beter presteert – de levenscyclus van de pagina is aanzienlijk vereenvoudigd en meer vatbaar voor webprogrammering – zelfs als het hetzelfde of een beetje langzamer zou zijn, zou het vanuit kwaliteitsperspectief de moeite waard zijn om naar over te schakelen.

Antwoord 7, autoriteit 10%

Ik denk dat het probleem hier is dat ongeacht hoeveel sneller ASP.Net MVC is dan de oude webformulieren, het geen verschil maakt, omdat de meeste tijd in de database zit. Meestal zitten uw webservers op 0-10% CPU-gebruik, wachtend op uw databaseserver. Tenzij u een extreem groot aantal hits op uw website krijgt en uw database extreem snel is, zult u waarschijnlijk geen groot verschil merken.

Antwoord 8, autoriteit 9%

De enige concrete cijfers die ik kan vinden die afkomstig zijn van vroege ASP.NET MVC-ontwikkeling staat in deze forumthread:

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

Rob Connery bevestigt zelf enigszins de bewering dat ScottGu heeft beweerd dat ASP.NET MVC 8000 verzoeken per seconde kan verwerken.

Misschien kunnen Jeff en zijn team een ​​hint geven van hun ontwikkeling van deze site.

Antwoord 9, autoriteit 4%

In tegenstelling tot de algemeen aanvaarde mening, maakt het geoptimaliseerde gebruik van webformulieren MVC volledig kapot in termen van onbewerkte prestaties. Webforms is hyper-geoptimaliseerd voor de taak om html veel langer aan te bieden dan MVC heeft gedaan.

Metrieken zijn beschikbaar op http://www .techempower.com/benchmarks/#section=data-r7&hw=i7&test=db

Elke afzonderlijke vergelijking mvc staat in de lagere-midden/lager-bovenste rangschikking van de lijst, terwijl geoptimaliseerde webformulieren gebruikt worden in de hogere-midden/bovenste-lagere rangschikkingen.

Anekdotische maar zeer serieuze validatie van deze statistieken, www.microsoft.comwordt geleverd door webformulieren en niet door MVC. Gelooft iemand hier dat ze niet voor MVC zouden hebben gekozen als het empirisch sneller was?

Antwoord 10, autoriteit 3%

Er is echt geen manier om dit te beantwoorden. MVC gebruikt standaard zelf de weergave-engine voor webformulieren en kan worden geconfigureerd om een ​​willekeurig aantal aangepaste weergave-engines te gebruiken, dus als u een prestatievergelijking wilt, moet u specifieker zijn.

Antwoord 11, autoriteit 3%

Ik begon ongeveer een jaar geleden met werken bij MVC, ik was geïnspireerd maar niet onder de indruk.

Ik verafschuw de weergavestatus en zie het als de wortel van alle kwaad in termen van ASP.NET. Dit is waarom ik het gewoon niet gebruik en om heel eerlijk te zijn, waarom zou je?

Ik heb in feite het ASP.NET MVC Framework-concept genomen en dat op mijn eigen manier gebouwd. Ik heb wel een paar dingen veranderd. Ik heb mijn controller-wrapping-code, of URL-routeringscode, gebouwd rond dynamische hercompilatie.

Ik zou zelfs zo ver willen gaan om te zeggen dat ASP.NET MVC-applicaties sneller zullen zijn op basis van hoe je het gebruikt. Als u WebForms volledig verlaat, bent u sneller omdat de levenscyclus en het objectmodel van ASP.NET gigantisch zijn.

Als je aan het schrijven bent, creëer je een leger… nee wacht, een legioen objecten die zullen bijdragen aan de weergave van je weergave. Dit gaat langzamer dan wanneer je de minimale hoeveelheid gedrag op de ASPX-pagina zelf uitdrukt. (Het maakt me niet uit om de abstractie van de engine te bekijken, omdat de ondersteuning voor ASPX-pagina’s in Visual Studio redelijk is, maar ik heb WebForms als concept en eigenlijk elk ASP.NET-framework volledig laten vallen vanwege code-opgeblazenheid of het niet kunnen wijzigen van de dingen die mijn aanvraag bedraden).

Ik heb manieren gevonden om te vertrouwen op dynamische hercompilatie (System.Reflection.Emit) voor het uitzenden van speciale objecten en code wanneer dat nodig is. Het uitvoeren van deze code is sneller dan reflectie, maar in eerste instantie gebouwd via de reflectieservice. Dit heeft mijn MVC gearomatiseerde framework geweldige prestaties gegeven, maar ook erg statisch getypt. Ik gebruik geen strings en naam/waarde-paarverzamelingen. In plaats daarvan gaan mijn aangepaste compilerservices in een herschrijft een formulierpost naar een controlleractie die een referentietype wordt doorgegeven. Achter de schermen gebeurt er van alles, maar deze code is snel, een stuk sneller dan WebForms of het MVC Framework.

Ik schrijf ook geen URL’s, ik schrijf lambda-expressies die worden vertaald in URL’s die later aangeven welke controlleractie moet worden uitgevoerd. Dit is niet bijzonder snel, maar het is beter dan het hebben van gebroken URL’s. Het is alsof u zowel statisch getypte bronnen als statisch getypte objecten had. Een statisch getypte webapplicatie? Dat is wat ik wil!

Ik zou meer mensen willen aanmoedigen om dit uit te proberen.

Antwoord 12, autoriteit 3%

De projecten gemaakt met visual studio. Een daarvan is mvc4-sjabloon, een andere is WebForm (traditioneel).
En bij het maken van een belastingstest met WCAT, is dit het resultaat,

MVC4 is vrij traag dan WebForms, enig idee?

MVC4

• kon ongeveer 11 rps halen
• rps is vrij laag zowel 2-cpu als 4-cpu server

WebFormulieren (aspx)

• kan boven de 2500 rps komen

• de prestatiemoordenaar is gevonden dat het een bug is van MVC Bata of RC.
  En de prestaties zouden worden verbeterd zodra ik Bundles-dingen verwijder. De nieuwste versie heeft dit nu opgelost.

Antwoord 13

Prestaties zijn afhankelijk van wat u doet… Meestal is MVC sneller dan asp.net, vooral omdat Viewstate afwezig is en omdat MVC standaard meer met terugbellen dan met terugbellen werkt.

Als u uw webformulierpagina optimaliseert, kunt u dezelfde prestaties leveren als MVC, maar het zal veel werk zijn.

Bovendien zijn er veel nugets voor MVC (en ook voor Webform) om u te helpen de websiteprestaties te verbeteren, zoals het combineren en verkleinen van uw css en javascripts, uw afbeeldingen groeperen en ze als sprite gebruiken, enzovoort.

De prestaties van de website zijn sterk afhankelijk van uw architectuur. Een schone code met een goede scheiding van zorg zal u een schonere code geven en een beter idee van hoe u de prestaties kunt verbeteren.

U kunt deze sjabloon “Neos-SDI MVC-sjabloon bekijken ” die voor u een schone architectuur zal creëren met standaard veel prestatieverbeteringen (kijk op de MvcTemplatewebsite) .

Antwoord 14

Ik deed een klein VSTS-laadtestexperiment met wat basiscode en ontdekte dat de responstijd van ASP.NET MVC twee keer zo snel was in vergelijking met ASP.NET-webformulieren. Hierboven is de bijgevoegde grafiek met de plot.

U kunt dit laadtestexperiment in detail lezen in dit CP-artikel https://www.codeproject.com/Articles/864950/ASP-NET-MVC-vs-ASP-NET-WebForm-performance-compari

De test is uitgevoerd met de onderstaande specificaties met behulp van VSTS en telerik load-testsoftware:-

Gebruiker laadt 25 gebruikers.

Duur van de test was 10 minuten.

Machineconfiguratie DELL 8 GB Ram, Core i3

Project werd gehost in IIS 8.

Project is gemaakt met MVC 5.

Er werd uitgegaan van een netwerk-LAN-verbinding. Dus deze test houdt voorlopig geen rekening met netwerkvertraging.

Browser in de test geselecteerde Chrome en Internet Explorer.

Er zijn tijdens de test meerdere metingen gedaan om het gemiddelde van onbekende gebeurtenissen te berekenen. Er zijn 7 metingen gedaan en alle metingen zijn in dit artikel gepubliceerd als lezing 1, 2 enzovoort.