102

I found some wild remarks that ASP.NET MVC is 30x faster than ASP.NET WebForms. What real performance difference is there, has this been measured and what are the performance benefits.

This is to help me consider moving from ASP.NET WebForms to ASP.NET MVC.

tereško
  • 58,060
  • 25
  • 98
  • 150
GateKiller
  • 74,180
  • 73
  • 171
  • 204

14 Answers14

69

We haven't performed the type of scalability and perf tests necessary to come up with any conclusions. I think ScottGu may have been discussing potential perf targets. As we move towards Beta and RTM, we will internally be doing more perf testing. However, I'm not sure what our policy is on publishing results of perf tests.

In any case, any such tests really need to consider real world applications...

GateKiller
  • 74,180
  • 73
  • 171
  • 204
Haacked
  • 58,045
  • 14
  • 90
  • 114
  • 13
    Now that MVC has been released, is there any update on releasing the perf results? – chris Apr 24 '09 at 17:23
  • 6
    Just voting this up because the 5,999 rep score before was hurting my eyes :( – Damien May 01 '09 at 10:09
  • 2
    By this time, you must surely have some numbers. Care to update your answer? Or did you find that the pesky policy forbids it? – tvanfosson Jun 10 '10 at 11:28
  • 7
    The number is 42. :) In general, our numbers will probably be useless to real world apps so we as a rule don't give them out. However, I know of other teams at Microsoft building large scale websites who show favorable numbers. In other words, any perf issues are more likely going to be due to programmer mistakes than any inherit issues in the framework. Typically interactions with the database and external services are the culprits. :) – Haacked Jun 15 '10 at 21:21
  • True! Please update this! Maybe not benchmarks but a brief idea, are they on par or is mvc a wee bit better on perf? – gideon Dec 14 '10 at 17:21
48

I think this will be a hard question to definitively answer as so much will depend on A) how you implement the WebForms application, and B) how you implement the MVC application. In their "raw" forms, MVC is likely faster than WebForms, but years and years of tools and experience have produced a number of techniques for building fast WebForms applications. I'd be willing to bet that a senior ASP.NET developer could produce a WebForms application that rivals the speed of any MVC application- or at least achieve a negligible difference.

The real difference- as @tvanfosson suggested- is in testability and clean SoC. If improving performance is your chief concern, I don't think it's a great reason to jump ship on WebForms and start re-building in MVC. Not at least until you've tried the available techniques for optimizing WebForms.

Community
  • 1
  • 1
Todd
  • 5,538
  • 1
  • 31
  • 34
  • Great answer Todd (how surprising for a developer evangelist to actually have a pragmatic response). The only thing you got wrong is in the raw implementations webform is indeed substantially faster. – Chris Marisic Nov 27 '13 at 21:56
42

It decreased one of my pages from 2MB payload, to 200k, just by eliminating the viewstate and making it bearable programatically to work with the submitted output.

The size alone, even though the processing was the same will create vast improvements in connections per second and speed of the requests.

DevelopingChris
  • 39,797
  • 30
  • 87
  • 118
  • 31
    you could have fixed that pesky large viewstate without MVC too – Andrei Rînea Aug 17 '09 at 07:20
  • 1
    Just to elaborate ViewState can be turnd off @ page level or in web.config – bbqchickenrobot Oct 01 '10 at 04:05
  • 8
    yes but in mvc its a sane default not a design decision that forces you to leave all controls and the vendors that claim to just work on web forms, by making web forms "mis behave" by removing its back bone. I don't disagree you could just recode that page, but the whole app was better without viewstate. – DevelopingChris Oct 02 '10 at 02:14
  • then dont you think it is the worst decision of yours to port the whole app to MVC rather than turning the viewstate off in web.config? and no, viewstate is not the backbone. only if you have researched, viewstate can be kept in cache as well as sessions. – Simple Fellow Aug 29 '14 at 10:12
29

I think that many of the people who think that WebForms are inherently slow or resource intensive are placing the blame in the wrong place. 9 times out of 10 when I am brought in to optimize a webforms app there are way too many places where the apps authors misunderstand the purpose of the viewstate. I'm not saying that the viewstate is perfect or anything, but it is WAY too easy to abuse it, and it is this abuse that is causing the bloated viewstate field.

This article was invalueable in helping me understand many of these abuses. https://weblogs.asp.net/infinitiesloop/truly-understanding-viewstate

In order to make a valid comparison between MVC and WebForms we need to be sure that both apps are using the architectures correctly.

Kols
  • 3,641
  • 2
  • 34
  • 42
Ariel
  • 872
  • 6
  • 11
14

My testing shows something between 2x and 7x more req/sec on MVC, but it depends how you build your webforms app. With just "hello world" text on it, without any server side control, mvc is around 30-50% faster.

Hrvoje Hudo
  • 8,994
  • 5
  • 33
  • 42
12

For me the real "performance" improvement in MVC is the increase the testable surface of the application. With WebForms there was a lot of the application that was hard to test. With MVC the amount of code that becomes testable basically doubles. Basically all that isn't easily testable is the code that generates the layout. All of your business logic and data access logic -- including the logic that populates the actual data used in the view -- is now amenable to testing. While I expect it to be more performant as well -- the page life cycle is greatly simplified and more more amenable to web programming -- even if it were the same or a little slower it would be worth switching to from a quality perspective.

tvanfosson
  • 524,688
  • 99
  • 697
  • 795
  • I would truly love to know why someone downvoted this answer. – tvanfosson Jun 10 '10 at 11:31
  • My sense is that it might get downvoted because a well designed ASP.NET web forms application is just as testable as an MVC application. My experience with developing both is that MVC forces you into a clean programming model (which is one of its greatest strengths, IMO). Web forms lets you do lazier things, but it's still very possible to have the same testable surface in web forms. That's my guess, anyway. – dudemonkey Oct 19 '11 at 13:17
  • Razor views literally encourage the embedding of code inside the view. That's not testable, and it doesn't bode well for separation of concerns. Just because MVC makes you write controllers, doesn't mean you can't burke it all up if you don't know what you're doing. A skilled dev will get just as much performance out of WebForms (or more) than MVC, and will have a virtually identical "testable surface". – Richard Hauer Sep 01 '16 at 15:01
  • @RichardHauer that was literally not true when I wrote this but they have improved on that. Since WebForms doesn't seem to have a future in .NET Core, it seems to be a moot point. – tvanfosson Sep 01 '16 at 15:15
  • @tvanfosson Agreed - it's moot now. Not sure which bit you think is not true, perhaps you object to my use of "literally"? Anyway, the newer versions of MVC with TagHelpers do help to break the habit of putting code into layouts which might finally make it all work for me. Appreciate this post is quite old of course, but even at the time, a well constructed WebForms form is very fast with none of the "magic wiring" of MVC and no code embedded in the view at all. – Richard Hauer Sep 09 '16 at 03:21
  • @RichardHauer when I wrote this the changes to WebForms that allow dependency injection and increase testability didn't exist. Code behind was inherently untestable. You could move significant amounts to libraries for testing but there was always going to be some code you couldn't test - like data binding. – tvanfosson Sep 09 '16 at 13:01
7

I think the problem here is that no matter how much faster ASP.Net MVC is than the old webforms, it won't make a difference, because most of the time taken is in the database. Most of the time, you web servers will be sitting at 0-10% CPU usage just waiting on your database server. Unless you get an extremely large number of hits on your website, and your database is extremely fast, you probably won't notice a big difference.

Kibbee
  • 65,369
  • 27
  • 142
  • 182
6

The only concrete numbers I can find which are from early ASP.NET MVC-development is on this forum-thread:

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

Rob Connery himself somewhat confirms statement that ScottGu has claimed that ASP.NET MVC can serve 8000 requests per second.

Maybe Jeff and his crew can give some kind of hint from their development of this site.

Seb Nilsson
  • 26,200
  • 30
  • 103
  • 130
3

Contrary to the accepted opinion, optimized webforms usage completely kills MVC in terms of raw performance. Webforms has been hyper-optimized for the task of serving html far longer than MVC has.

Metrics are available on http://www.techempower.com/benchmarks/#section=data-r7&hw=i7&test=db

Every single comparison mvc is on the lower-middle/lower-upper rankings of the list, while optimized webforms usage places in the upper-middle/upper-lower rankings.

Anecdotal but very serious validation to these metrics, www.microsoft.com is served by webforms not MVC. Does anyone here believe that they wouldn't have chosen MVC if it was empirically faster?

Chris Marisic
  • 32,487
  • 24
  • 164
  • 258
2

The projects created with visual studio. One is mvc4 template, another is WebForm (tranditional). And when make load test with WCAT, this is the result,

MVC4 is quite slow than WebForms, any ideas?

enter image description here

MVC4

  • could get about 11 rps
  • rps is quite low both 2-cpu or 4-cpu server

enter image description here

WebForms (aspx)

  • could get above 2500 rps

  • the performance killer has been found that it's a bug of MVC Bata or RC. And The performance would be improved once i remove Bundles things. Now the latest version fixed this.

Kols
  • 3,641
  • 2
  • 34
  • 42
jihe.wei
  • 11
  • 2
2

There's really no way to answer this. MVC uses the Web Forms view engine by default itself, and can be configured to use any number of custom view engines, so if you want a performance comparison you'll have to be more specific.

Gerald
  • 23,011
  • 10
  • 73
  • 102
2

I started out work in MVC about a year ago, I was inspired but not impressed.

I loath the view state and see it as the root of all evil in terms of ASP.NET. This is why I just don't use it and to be perfectly honest why would you?

I took basically the ASP.NET MVC Framework concept and built that in my own way. I changed a couple of things though. I built my controller wrapping code, or URL routing code around dynamic recompilation.

Now, I would go as far as to say that ASP.NET MVC applications will be faster based on how you use it. If you completely abandon WebForms you'll be faster becuase the ASP.NET life-cycle and object model is humongous.

When you're writing you're instantiating an army... no wait, a legion of objects that will participate in the rendering of your view. This is gonna be slower than if you where to express the minimal amount of behavior in the ASPX page itself. (I don't care about view engine abstraction because the support for ASPX pages in Visual Studio is decent, but I've completely dropped WebForms as a concept and basically any ASP.NET framework due to code bloat or not being able to change the things that wire my application).

I've found ways of relying on dynamic recompilation (System.Reflection.Emit) for emitting special purpose objects and code whenever needed. The executing of this code is faster than reflection but initially built through the reflection service. This has given my MVC flavored framework great performance but also very statically typed. I don't use strings and name/value pair collections. Instead my custom compiler services goes in a rewrites a form post to a controller action being passed an reference type. Behind the scene there is a lot of things going on but this code is fast, a lot faster than WebForms or the MVC Framework.

Also, I don't write URLs, I write lambda expressions that get translated into URLs that later tell which controller action to invoke. This isn't particularly fast but it beats having broken URLs. It's like if you had statically typed resources as well as statically typed objects. A statically typed web application? That is what I want!

I would encourage more people to try this out.

John Leidegren
  • 59,920
  • 20
  • 131
  • 152
  • 2
    So this is not an direct answer to the question? It's however related, and it makes a couple of good points. But hey, it's something I built for my own needs, and it suits me perfectly fine. I also enjoy sharing my ideas, even if very few people understand why. – John Leidegren Oct 16 '09 at 21:27
  • 1
    Well, you don't have to change your vote, but you don't have to put a down vote on it, because it is not 'the' answer. If you take a while a look into the text there's several things that points to ASP.NET MVC being faster than WebForms and why that's the case. And it boils down to things like reflection and the object model and ViewState overhead of WebForms. – John Leidegren Oct 17 '09 at 10:59
  • @John - now that MVC2 is out with improved model binding, validation, strongly-typed helpers, etc., how you would evaluate it compared to your method? – tvanfosson Jun 10 '10 at 11:34
  • MVC2 is a lot better, I believe it has pretty much replaced what I was building at the time (with MVC1 in beta). I ran into quite the ordeal of problems in relation to what I was trying to build on top of ASP.NET without opting out of the existing tooling. Sufficient to say, I learned a lot and eventually brought this into production. I now realize that the current tooling/framework (VS/ASP.NET/C#) isn't really fit for this stuff and eventually if you wanna go down this road, you'll need to invest in your own compilers/model-checking stuff for some things to work in your favor. – John Leidegren Jun 10 '10 at 12:59
  • I didn't think much of ASP.NET MVC at that time. It lacked things I knew I wanted. But, I had to spend a lot of time developing, testing and figuring these things out. I still think that the static aspect of the web framework I was building is superior to MVC in that regard but the C# compiler is inefficient for solving that problem. You need some language/compiler that allows greater flexibility when it comes to meta programming. I had to do a lot of that at runtime and it was often impossible to cache compiled instances so I had to dynamically recompile things a lot. – John Leidegren Jun 10 '10 at 13:08
  • I ended up building a lot of code generation tools as well to make it play nice with the database. I was using Linq-to-Sql and the tooling that ships with Linq-to-Sql was pretty much useless. I used simple naming conventions to model type enumerations, entities and associations and then mapped that in the attribute meta model way of Linq-to-Sql. Though, in the end I had a very elegant declarative model. In which things like data binding, validation and CRUD was pretty much done automatically. – John Leidegren Jun 10 '10 at 13:16
  • I had great fun and went through great pain to see this through. Though what I ended up realizing is that this statically typed web, it requires that you push work into code generation and dynamic compilation so that you can work you way forward in a declarative manner. I believe this is a trend that you see showing up in more and more places. – John Leidegren Jun 10 '10 at 13:42
  • seems like you had a lot of time to do this thing. my manager just discusses, assigns tasks to be completed within a fixed amount of time. there is not even time to research much. – Simple Fellow Aug 29 '14 at 10:23
  • @SimpleFellow I have taken the time. As a manager there has to be a strong business case to be able to devote the time to work on things like this. If it really results in an edge over competition. Sometimes communication is the hardest part but if you can sit down together and talk about why it's important but be prepared to hear the other side of the story. Everyone often have very good reasons for why some things needs to get done. If all fails, look for employment elsewhere but only if you absolutely sure you've tried everything. – John Leidegren Sep 03 '14 at 07:30
1

Performance depends on what you are doing... Usually MVC is faster than asp.net mostly because Viewstate is absent and because MVC works more with Callback than Postback by default.

If you optimize your webform page you can have the same performance as MVC but it will be a lot of work.

Also, their is a lot of nugets for MVC (and also for Webform) to help you to improve website performance like combine and minify your css and javascripts, group your images and use them as a sprite, and so on.

Website's performance depend greatly of your architecture. A clean one with good separation of concern will bring you a more clean code and a better idea of how improve performance.

You can take a look at this template "Neos-SDI MVC Template" which will create for you a clean architecture with lots of performance improvements by default (check MvcTemplate website).

Jeff Lequeux
  • 276
  • 4
  • 5
-1

enter image description here

I did a small VSTS load test experiment with some basic code and found ASP.NET MVC response time to be twice faster as compared to ASP.NET Webforms. Above is the attached graph with the plot.

You can read this load test experiment in details from this CP article https://www.codeproject.com/Articles/864950/ASP-NET-MVC-vs-ASP-NET-WebForm-performance-compari

Test was conducted with the below specifications using VSTS and telerik load test software:-

User load 25 users.

Run duration of test was 10 minutes.

Machine config DELL 8 GB Ram, Core i3

Project was hosted in IIS 8.

Project was created using MVC 5.

Network LAN connection was assumed. So this test does not account for network lag for now.

Browser in the test selected Chrome and Internet explorer.

Multiple reading where taken during the test to average unknown events. 7 readings where taken and all readings are published in this article as reading 1 , 2 and so on.

Kols
  • 3,641
  • 2
  • 34
  • 42
Shivprasad Koirala
  • 27,644
  • 7
  • 84
  • 73
  • Your testing methodology is bad, and heavily biased, and your conclusions are invalid. A properly built WebForms application is testable, has proper separation of concerns, and has minimal payload overhead. While MVC has no page lifecycle event loop, it has routing and view execution to contend with. Your articles on this topic on CP are heavily biased. – Richard Hauer Sep 01 '16 at 14:50
  • A properly & carefully built application even in a worst technology would work miracles. ASP.NET page life cycle definitely has more payload as compared to routing & view execution as it deals with HTML UI generation. Routing is a part of ASP.NET framework so even in normal webforms they do exist. One thing i agree if you do not write code behind your performance will be equivalent to MVC.But Webform toolbox is so tempting that code behind becomes a integral part of it. While MVC does not allow me do that at all. I love how in razor they have disabled the design view and code behind. – Shivprasad Koirala Sep 02 '16 at 00:26