Asp.Net application performance

Question

I see the web development world in .Net is now divided into Asp.Net Webforms and MVC and there is 3rd category who prefer to use both in the same application.

My question: ViewState is often treated as evil and the major performance bottleneck in majority of the applications. But if we use it correctly then I see no problems at all. There is too much buzz around Asp.Net MVC 3.0/4.0 beta and it being without ViewState.

However my concern is, how can Asp.Net MVC help speed up performance because as I see it we bind controls in

if (!IsPostback) {}

where in Asp.Net MVC we bind the control each and every time and possibly make database request each time a form is posted. Doesn't Asp.Net Winforms have upper hand in this? Can it be guranteed that Asp.Net MVC will perform better in all cases?

Edit: I do not wish to start any controversy and further I am only talking about the Asp.Net code not about performance after Javascript minification, CSS minification and all other tricks.

Answer 1

I can't say that MVC's advantage is performance, though I think it probably is faster. It's advantage is not dealing with the winforms-like lifecycle of controls. Development does not become more complex the more there is on a single page, where with controls, their lifecycle events can oftent step on each other if not done right.

Regarding performance, MVC's lifecycle is static. There are a handful of events that occur, but that doesn't change much. Performance concerns are in your action method. With webforms, several events and control recreation occurs on every postback, often even if the controls aren't used or visible. There is much more waste in webforms, which makes MVC by contrast lean and open to better performance.

Answer 2

mvc (be it MS or any other framework) are more inline with the stateless nature and concepts of web.

webforms is designed to make web development behave more like a stateful desktop client. this is why page events, postback and viewstate exist.

I have seen viewstates that are 50MB. this definitely hurts performance. using an mvc framwork you can reduce page size rather quickly. however the advantages in mvc are 1. it's simplicity (vs webforms page life cycle) and 2. it's extensiblity.

if you don't like the default implementation of the controller factory, or validation, or view engine you can swap it out in mvc. with webforms you cannot.

Answer 3

All excellent answers here, but I'm going to throw my 2 cents in as well.

When you bind controls with if (!IsPostBack) , you are writing an encrypted viewstate field to the webforms page. During the next request, all of that state is sent up to your server and decrypted / deserialized. If you had a GridView on the page, all of its rows would be in the viewstate, so you would not need to make another db request to databind it again.

In this sense, it could make performance better on your server . However, as others here have said, you take the network hit of sending all of that viewstate up to the server. Also, you need to push the state back down. It sounds like you are keeping your viewstate light on purpose to overcome potential viewstate abuses and make webforms perform better. That is definitely a good practice, because viewstate is often abused or even ignored.

Consider the example where you are pushing down a paginated GridView to the client. If your GV contains 15 rows, you may well be getting better performance by pushing it all down to the client, deserializing it on the way back up, and not hitting the db after the first load. When your GV contains 1500 rows though, end users would probably see better performance if you did not send it down in viewstate, and instead hit the db during each pagination request. (However as soon as they link from the GV to a detail page, then click the "Back" button, they will be asked to repost their data -- which is always annoying, no matter how many rows there are).

Ultimately, the performance may look better to you when you are developing on the machine that is serving up and consuming the webforms pages. But depending on the size of your viewstate, people who access the content over a network might not see the kind of speed as you. It all depends on how fat your viewstate is .

I think one of the reasons a lot of MVC fans like it is because they only need to send the minimal request to the server that is needed to perform a specific action . Instead of having 1 monolithic form that submits all data & state for all webcontrols on a page, we can split up our forms and only send sections or chunks to different actions, instead of deserializing the entire form.

As others have said here, the short answer to your question is NO, MVC will not always be faster or perform better than webforms. There is no black and white. In many cases it can and does, but again as others have said, some apps are better suited for webforms . Also, is performance your only concern? MVC does have black & white advantages over webforms in other areas, even if performance may always "depend".

Answer 4

It is my personal opinion that MVC is better suited for sites that need to display lighter content. But if you need to build grids for day traders, then Web Forms have the upper hand.

ASP.net MVC does not bind controls in the way that asp.net web forms does.

You need to use JQuery in order to do this. Jquery has excellent performance.

http://www.codeproject.com/Articles/305308/MVC-Techniques-with-JQuery-JSON-Knockout-and-Cshar

It also important to mention that MVC\\jquery require a much higher level of expertise. So you have to watch the bottom line when it comes to cost. Cost is usually ignored by programmers, but it plays an important role in any project.