Hi,
I've inherited a large project and am now in charge of adding AJAX support to it, in order to make it seem more responsive to the users, and to avoid having to perform a complete postback every time the users want to navigate to a different control.
However, my first experiences with using AJAX.NET seem to be a bit disheartening. I added a simple UpdatePanel to the form, as well as a button and a textbox inside of it. The button has a server-side call to update the textbox with DateTime.Now.ToLongTimeString(). Now, whenever I call it, it takes at least 4 seconds to perform a round trip to the server and back with the time. This is unacceptable for our purposes, so I looked into the cause. Our pages are, to put it politely, freaking huge. For the 4-second one, the page is over 100k. So I did some testing, and it appears that on an ajax-postback, the entire page is being posted back to the webserver, constructed, and updated, and finally the relevant pieces (mainly the contents of the update panel) are sent back to be updated.
On the web I've seen many references to so-called "partial postbacks", which I took to mean that the AJAX call is only going to send the contents of the update panel back to the webserver, and not the entire page. Am I incorrect thinking this? In other words: is the entire web page always going to be sent back to the server, even with AJAX calls, or am I missing something important here?
Thanks for your time.
Hi
What you are getting is the default behaviour. What happened in ASP.NET AJAX is that page is posted back to the server and all the page events are rendered as such as in normal postback.
What happens actually, when you put the controls inside Update Panel, only the portion of the data that is inside Update Panel renders back to the server but the complete life cycle of the page behaves normally as normal postback.
So if you want the real power of AJAX, you have to sync with View State and all other stuff.
Hope that helps you..
Bye
Ron,
Your issue there could be ViewState size. Even if the page sends and receives only the data relevant to the UpdatePanel to refresh, ViewState is still transmitted and the complete page life cycle occurs.
Just turn trace on and check you ViewState size. If it's huge, try to find the controls that may have it disabled. If you manage to reduce it's size, your AJAX page will be "faster".
Also, something that really helped me to reduce "page size" and, therefore, AJAX "speed", was to enable IIS dynamic compression.
Cheers,
Juan
Yeah, compression helps, also make sure that your running in compilation mode='release' (in debug the scripts are 3x or more larger). Also, if there's no way to tighten up your viewstate, thne it might be worth it to look at other refresh techniques (more js heavy, less plug-n-play) like PageMethods or Webservices. Those will reduce the traffic to only that which is necessary.
I have found that using update panels and MS ajax will be quite a change in how you philisophically go and layout a page. This is something you will find out over the time you are working on your app. For instance, I had the same type of problem you did with viewstate and page size. I found that I had a gigantic drop down list that was filling up my viewstate and gridviews with lots and lots of records in them. My solution was to get rid of the dropdownlist by using a quick search repeater with a select button on each record. This, in a world with full postbacks would be cumbersome, but with updatepanels becomes quite easy. Second, I have gone the route of creating interfaces similar to regular applications like outlook with a record browse on the left and context on the right. The outer page with browsing is a page and the record is a page that gets popped in an iframe. This allows for a quickie javascript double click to open the record in its own window and a single click to open the record in the context window.
Another big help is managing your refreshes. You will find that using the 'updatemode="conditional"' setting in your update panels will also help to speed up the page. When an updatepanel is left without the conditional mark it postsback on each partial postback. Sometimes the implementation of this can be a bit tricky because you have to call the updatepanel.update() method in codebehind, but the benefit is definately worth the hassle.
Finally, shrinking down what you have in your updatepanels will definately help you keep your page moving quickly. If your entire page with huge drop down lists, etc.. works off one gridview this will be troublesome. When you can put your updatepanel around one textbox, then an updatepanel around the update button, you will be well on your way to super fast processing.
Remember that a partial postback posts back anything within the update panel and, therefore, the more you have in the updatepanel, the more that needs to be sent back to the browser.
Great thoughts, and advice. I'll echo the fact that it's a real balancing act, though. Too much granularity in your updates and you lose scalability. Too little and you kill your bandwidth and users suffer. Good page design can go along way to help you keep the balance.
