20

I've been tasked to help improve performance on an asp.net (4.5) webforms application that unfortunately uses updatepanels. They are really evil. But getting rid of them isn't so simple as the system is tied up to a whole slew of things. I've been able to get rid of some of the update panels that were unnecessary.

In any event this is a CRM type system so imagine you go to a details page of say a customer. Inside this details page of a customer you have some general customer info. At the bottom of the page there are tabs. For instance, a customer details page can have tabs for "Contacts" that work for that customer, "Products" that the customer sells, "Ratings" for the customer..etc. Each one of these tabs is basically a div and wrapped around it is an update panel. Initially only the first tab is loaded. As you click the tab an async call is made which loads the tab with data. So basically you have a page that looks something like this: pseudocode:

updatepanel for entire page
  html  

  <!-- tabs -->

  updatepanel for contacts sub panel
     contacts html
  /updatepanel

  updatepanel for products sub panel
     products html
  /update panel

  updatepanel for ratings sub panel
     ratings html
  /update panel

/updatepanel end the entire page

The tabs as mentioned are divs and are basically jquery tabs. At first I noticed every single update panel on the page had its updatemode set to always. I immediately changed the updatemode to conditional and explicitly called Update() when I needed the update panel to update. A very small improvement. I then noticed the initial update panel (the one used for the entire page) had its ChildrenAsTrigger property set to true...so I changed that to false. Very small improvement.

I then began testing the page again to see how performance was...still very crappy. In fact when the page first loads and the first tab loads the page is very fast. When I click on another tab (it loads the sub panel data via an async process by calling a hidden button server side event to load the data). So this is definitely not true ajax but hey its what we have. So basically the server side event simply binds some data to a grid on that tab. Performance of getting the data is absolutely fine - that is not my issue.

My issue is now as I scroll up and down the page performance is starting to degrade. Once I click on another tab or another 2-3 different tabs performance of getting the data is still awesome..but after I get the data and I scroll the page its horrendous. The scroll bar even jumps at times as it cant keep up with how fast I want to navigate the page.

I don't know what else to do to speed up this page aside from dumping the updatepanels completely however there is way too much work and time to do this. So far I have tried the following:

  • eliminated as many update panels as what was not needed
  • changed update mode from always to conditional
  • changed childrenastriggers to false
  • fixed any bugs / optimized as much as I could on the asp.net / js side

What else can I do to fix this or what else could be causing the slow delay? As mentioned the getting of the data is very fast, its when I move up and down (scroll) the page is what is very choppy. I followed msdn's recommendation for how update panels refresh.

Edit Update

I am still working on this to try to figure out a better way. I tried using this:

http://aspadvice.com/blogs/robertb/archive/2005/11/16/13835.aspx

Which allows me to treat the view state on the server side. The effect is the html markup has gotten rid of all the view state info however, the issue I still have that has not been solved is the fact that as I continue to do async postbacks by trigger events on the page my page slows down. What I mean by slows down is as I scroll up / down the page the performance is really bad. The scroll bar has to basically catch up with me as I scroll. So even getting rid of the generated viewstate info on the client side page I am still running into the issue that the scroll bar is very slow. This again happens due to events on the page such as a filter / click event or a sort or a page index change on a grid (basically anything that causes an async postback).

If anyone has additional ideas feel free to chime in.

JonH
  • 32,732
  • 12
  • 87
  • 145
  • sounds like 'painting', which makes me think 'memory', which makes me think 'caching'. maybe play with caching (server, not local), turning it off (or on). (i guess that's a server thing so probably not relevant, but worth checking/knowing what's happening at least.) have you tried other machines? – wazz Jul 14 '15 at 22:09
  • Yes happens to anyone and everyone. It's probably the viewstate info that is spit out of the update panels, but I cannot disable viewstate due to the nature of the app. And I'm already compressing the viewstate – JonH Jul 14 '15 at 22:52
  • Nasty things, update panels. Make my skin crawl. I'd like to say re-write it all, quick, before the world ends. But, this problem seems like View State Bloat and Call-back domino-ing. Have you tried `Page.EnableViewState = false;`? Have you handled `ScriptManager.IsInAsyncPostBack` in `Init, Load, PreRender` and `Unload`? – Dave Alperovich Jul 14 '15 at 23:59
  • @dave if I set page viewstate to false I'd lose my view state and that is really needed. What do you mean on your second point when you mention have you handled IsInAsyncPostBack am I supposed to be doing something in those methods? – JonH Jul 15 '15 at 01:00
  • 1
    whatever your `Init, Load, PreRender` and `Unload` events do, should NOT be done on `IsInAsyncPostBack ` – Dave Alperovich Jul 15 '15 at 01:16
  • I don't think the comment makes it any different page load already checks of its not a postback, and it isn't a post back so it is already behaving correctly. – JonH Jul 15 '15 at 14:47
  • Possibly. Been forever since I've done Web Forms. Might try logging it to make sure. – Dave Alperovich Jul 15 '15 at 23:48
  • Related: http://forums.asp.net/t/1218137.aspx but still doesnt help me :(. Anyone else ? – JonH Jul 16 '15 at 18:29
  • Also related: http://stackoverflow.com/questions/31572986/why-is-telling-jquery-to-click-my-link-button-slowing-my-page-down?lq=1 – JonH Jul 22 '15 at 20:08
  • Are you mixing JQuery and Update Panel? – Dave Alperovich Jul 22 '15 at 20:17
  • I'm not sure what you mean by mixing. If you are asking if I am using both - unfortunately I am this is a fairly older project...and I wish I could use strictly jquery but there is so much stuff on this page with gridviews, and events on the gridviews that rely on the update panel. – JonH Jul 22 '15 at 20:21
  • Making async post-backs with update panel and without is what I mean by mixing. Update panels work hard to maintain viewstates. This is their strength and their performance problem. They keep track of each postback. If you make async postback with and without the update panel, You run the risk of double loading your viewstates yet again. – Dave Alperovich Jul 23 '15 at 11:35
  • Dave but see my edit where I keep viewstate on the server. The client side rendered HTML has no viewstate info – JonH Jul 23 '15 at 11:54

3 Answers3

6

Well finally I got this working...the issue was related to another recent question I had found here: Why is telling jQuery to click my link button slowing my page down?

The gist of it was that I was subscribing events on controls that were outside of my update panel. In effect, doubling, tripling, or attaching n events based on resubscribing in my jquery. See my link posted.

Community
  • 1
  • 1
JonH
  • 32,732
  • 12
  • 87
  • 145
0

Performance of getting the data is absolutely fine - that is not my issue.

My issue is now as I scroll up and down the page performance is starting to degrade.

Are you sure this is due to the async postback? How much data are you trying to display on the page at one time?

If the browser is performing multiple postbacks, then the update panels are probably to blame. But it sounds like the page loads and updates fine, and the browser is struggling to render the document. There's no way for us to tell for sure without more specific details about the page.

My suggestion is that it's possibly not an update panel problem, but instead a pagination problem. Do you have any options to break up your data and only show a few chunks at a time?

pokkanome
  • 347
  • 1
  • 9
  • It's not a lot of data, maybe 2 to 3 hundred rows. And it's a custom paging solution so you are only getting twenty five records at a time. Getting rid of the update panels gets rid of the issue. – JonH Jul 20 '15 at 21:18
  • Is the update panel only doing one postback at a time? I'm still vague whether the page is lagging due to multiple pending network calls, or if it's lagging due to the javascript trying to update the DOM. Do you have all 2-3 hundred rows loaded in the browser, or are you only requesting and displaying 25 rows at a time? – pokkanome Jul 20 '15 at 21:24
0

I had huge performance issues with treeviews having large data inside an update panel. If you have treeviews it can 'make' the page get a full postback on its own after the desired postback. Tracing will tell the tale. Ultimately I wrote an ajax wrapper and did the partial postbacks myself. Treeview can be a punk.

If you don't have a treeview please disregard.

edit: If it matters I had about 250 items in the treeview up to 4 deep.

Joe Johnston
  • 2,794
  • 2
  • 31
  • 54