Welcome to MSDN Blogs Sign in | Join | Help

WebTopics

IIS and ASP.NET Information and Tips from Microsoft Developer Support

News

  • All posts are provided "AS IS" with no warranties, and confer no rights. All the expressions expressed herein are entirely the bloggers own and not necessarily those of Microsoft. In addition, thoughts and opinions often change. Because a weblog is intended to provide a semi-permanent point-in-time snapshot, you should not consider out of date posts to reflect current thoughts and opinions.
Fix: UpdatePanel Async Postbacks Slow in Internet Explorer

We've seen a few issues recently where customers were experiencing very slow async postbacks via an UpdatePanel, but only in Internet Explorer. Other browsers worked fine. (When I say "very slow", I mean in the neighborhood of 30 seconds!) The cause for this isn't a mystery to us.

Because of the way our HTML viewer (mshtml.dll) was designed, Internet Explorer is slow to iterate through large DOM collections. As it happens, the PageRequestManager class has a method called _destroyTree that does just that. It uses a for loop to iterate through all of the DOM nodes in the UpdatePanel's DIV. It does this on the client (the browser) before the request to the Web server is ever kicked off, and if you have a large DOM in your UpdatePanel, you might see a very long delay in Internet Explorer when this occurs.

If you're experiencing this kind of problem, I have good news. We've fixed this for the next version of ASP.NET, and we also have some code that you can use in your applications now to mediate the problem. You can find the updated code in our Knowledge Base at http://support.microsoft.com/?kbid=2000262.

Update 9/29/2009:
Removed the code from this blog post and referenced KB instead. We did this so that we can service the KB article without having to update this post in the future.

 

Posted: Thursday, June 18, 2009 7:47 AM by jamesche
Filed under: ,

Comments

velio said:

Hey,

The code is broken.

Opening curly brace of function body is missing and it gives JS error on the page.

Looking forward for the proper code.

Thanks in advance.

Regards,

# June 19, 2009 1:51 AM

jamesche said:

Sorry about that, Velio. Must have been a stray keystroke when I transferred it over. I've fixed it.

Jim

# June 19, 2009 11:12 AM

velio said:

Great job and tremendous piece of code, Jim.

Initial usage and tests shows fantastic improvements on UpdatePanel performance.

Regards

# June 21, 2009 2:25 AM

jamesche said:

Thanks, Velio. The credit goes to our product group. I appreciate the update.

Jim

# June 22, 2009 11:04 AM

trung pham said:

This is really great. Yes it save a lot of loading page in update panel. Thank you very much

# July 19, 2009 2:22 PM

PeteB said:

This is fantastic, my web page works like a dream now.  

I have been delaying a release of a whole batch of changes due to slow postbacks and you have just saved me from rewriting the whole page using webservices and other time consuming developments.  Great stuff.

# August 21, 2009 11:36 AM

peter cefalu said:

I am getting a js error 'nodetype' is null or not an object. Any thoughts?

# September 29, 2009 1:47 PM

jamesche said:

Peter,

Do you have a URL or can you share your page?

Jim

# September 29, 2009 2:38 PM

Peter Cefalu said:

No I do not. I did see that you had updated code in your Knowledge Base article and changed it. That fixed the error but my update panels seem even slower. I am not even hitting a DB or anything. Just updating labels with user selections in a form, kind of a summary of what was selected. We use IE6 as this company has not even updated to IE7 yet. Although it is slow in IE7 and 8 as well. Probably just my code. It is instantaneous on my development machine. I was surprised at how slow it is on the live server. It kind of makes it useless now. Oh well, live and learn.

# September 30, 2009 3:47 PM

jamesche said:

Couple of things, Peter. First of all, if the code is entered correctly, you shouldn't get an error whether you're using the latest updated code or the previous code. All I can guess is that there must have been a typo.

If you are still experiencing slowness, it's not caused by this issue. If you want assistance in tracking it down, you can open a support incident with us and we can help.

Jim

# September 30, 2009 3:54 PM

Peter Cefalu said:

Well Jim,

I triple checked the code and kept getting the error. It obviously did not like something in the page. There was no typo, but thanks for assuming I am an idiot. The latest version does not throw the error. I do agree that something else is causing the slowness. I am afraid I cannot share any code with you to help fix this problem. Thanks for the offer. And it was a good idea to remove the code from here if it was not being updated.

# September 30, 2009 4:03 PM

jamesche said:

Sorry you took it that way, Peter. I certainly wasn't assuming you were an idiot. Because the code was tested thoroughly and is in use by many people without any errors, I surmised that you might have a typo. I would never say someone is an idiot for having a typo! I've had pelnty of them myself. :) Everyone does.

We are updating the code if we can improve on it, but we wanted to make sure to have it in only one place so that it didn't have to be updated twice. The code is available in the KB article linked on this post.

Jim

# September 30, 2009 4:09 PM

Peter Cefalu said:

I really did not take it that way, just my dry humor I guess. I'm just really bummed that it did not help me. I showed the boss the functionality on my machine (where it is super fast) and he loved it. Now it is pretty much useless on the live version until I speed it up. I'll keep checking for updates though. Thanks.

# September 30, 2009 4:13 PM

jamesche said:

Understood, Peter. Funny thing is that when I originally posted this blog entry, I had a typo in the code. :)

Yeah, this code is designed to work around a very specific issue. If you don't see slowness in Firefox, that's an indicator that it may be this issue.

We have a lot of skill in troubleshooting performance issues like yours, so if you reach a dead end, open a case and we can help out!

Jim

# September 30, 2009 4:40 PM

Volodymyr Goncharov said:

It is very crucial to put the JavaScript "immediately before the closing </body> element". In other cases it may not work.

Thanks for the fix!

# October 1, 2009 5:09 AM
Leave a Comment

(required) 

(required) 

(optional)

(required) 

  
Enter Code Here: Required

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Page view tracker