ASP.NET MVC Performance

Question

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

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.

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.

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.

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.

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.

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.