ASP.NET MVC Performance

Question

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.

Solution 1

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...

Solution 2

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.

Solution 3

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.

Solution 4

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.

Solution 5

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.

View more solutions

Comments

[Jarrod Dixon]

After working with WebForms since they came out, I'll never willingly go back! MVC has stolen my <3 - and this site is running awesomely on Beta 5!

[Nick]

What's with all the revision rollbacks on this question..?

[GEOCHET]

@Nick: The OP is rolling back any of the edits, and deleting any comments explaining them.

[George Stocker]

@Rich B: Correct, he deleted about 5 of my comments.

[Jordan Ricks]

Needs an update now that we're getting close to MVC3 release.

[chris]

Now that MVC has been released, is there any update on releasing the perf results?

[Damien]

Just voting this up because the 5,999 rep score before was hurting my eyes :(

[Andrei Rînea]

you could have fixed that pesky large viewstate without MVC too

[John Leidegren]

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]

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.

[UpTheCreek]

Your users might - no viewstate.

[tvanfosson]

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]

I would truly love to know why someone downvoted this answer.

[tvanfosson]

@John - now that MVC2 is out with improved model binding, validation, strongly-typed helpers, etc., how you would evaluate it compared to your method?

[John Leidegren]

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]

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]

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]

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.

[edoloughlin]

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. :)

[bbqchickenrobot]

Just to elaborate ViewState can be turnd off @ page level or in web.config

[DevelopingChris]

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.

[gideon]

True! Please update this! Maybe not benchmarks but a brief idea, are they on par or is mvc a wee bit better on perf?

[Kristóf Horváth]

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.

[Chris Marisic]

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.

[Simple Fellow]

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]

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.

[John Leidegren]

@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.

[Richard Hauer]

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]

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".

[tvanfosson]

@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.

[Shivprasad Koirala]

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.

[Richard Hauer]

@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.

[tvanfosson]

@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.