First of all: I'm really confused about this problem so excuse me if the description below is vague.

My site is written in .NET4, ASP.NET WebForms and runs in different environments, some are IIS6, some IIS7 (or 7.5). Some use SSL, some doesn't.

Whenever I host in IIS7 it works fine, no matter browser or HTTP/HTTPS. When I host it in IIS6 I have a huge performance hit for Internet Explorer 7/8 (i.e. the site is really really slow). But only for sites not using SSL (i.e. HTTP). When SSL is enabled the site is much faster. The IIS6 sites are hosted on Windows Server 2003 x64 with Service Pack 2.

These problems started when I installed .NET4 and upgraded the site to use .NET4. The 32 bit version of .NET4 is used even though the server is x64.

When using fiddler/dynaTrace and similar tools we realize that the TRANSFER of the .aspx-file is much slower on IE7 and IE8 (IIS6 not using SSL). The normal transfer time is about 500ms but when using IE7 on a non-SSL IIS6 site we have times around 10-20 seconds (20-40 times as high). When we have high load times you can actually see image by image pop up on the screen. First a dropdownlist is drawn, then the text within it, finally the css that aligns the text within the dropdownlist. The page is rendered "progressively" very slowly so you can easily follow the rendering order.

We have some indications that compression could be the cause since IIS7 by default enables some compression that IIS6 doesn't.

Unfortunately I cannot provide any links or demos of this behaviour since it is a closed system.

1) In what way can enabling SSL improve the transfer time for the .aspx? Is it sent in bigger chunks or maybe even one big chunk?

2) What could be the reason that IIS7 is much much faster than IIS6 and could we tweak our IIS6 setup for it?

3) Any ideas on what could be wrong with our IIS6 setup or how I could improve performance?

Once again - sorry for the vague question but all ideas/tips/suggestions are appreciated.

2 Answers 2


Sounds like an interesting challenge. I've haven't seen anything exactly like this and I can't imagine a difference between http and https that would cause this.

The best way to troubleshoot this is to break it down into the smallest parts possible. Some possibly suggestions:

  • Try disabling compression on the IIS6 box to see if that resolves it
  • Try disabling caching, that's a possibility
  • Check Event Viewer for any clues
  • Try simple .htm pages, or calling the images directly
  • Try different sites or app pools on the IIS6 box to see if the issue reoccurs
  • Make sure there isn't a proxy of any type, or IDS or any other layer that may get in the way
  • Thanks for replying! I've tried enabling/disabling compression (properties on Web Sites node in IIS6) - no real effect here. I'm not sure if I have to "manually" edit the metadatabase to include more files such as aspx, css, js etc. I have not tried this (yet)
    – mikeesouth
    Apr 5, 2011 at 9:06
  • No real clues in event viewer, unfortunately... No proxy/IDS/VPN or similar. No difference if I change pools/sites. I have the same problem on several sites and also on different physical machines/installations.
    – mikeesouth
    Apr 5, 2011 at 9:06
  • I will try with simple .htm pages and try to fill them with test data/images in order to get some size. Good tip!
    – mikeesouth
    Apr 5, 2011 at 9:07
  • Worth noting is that the network speed greatly affects the performance. I tried to reproduce the problem locally but the network is just too fast so I can't really see it. However I exposed my local test installation externally and tried from a remote machine with slow network and the same problem occurs.
    – mikeesouth
    Apr 5, 2011 at 9:10
  • What exactly do you mean by caching in this case? Can I configure it on the serverside in IIS6?
    – mikeesouth
    Apr 5, 2011 at 9:12

A big thanks to Scott Forsyth for all the help and tips. The problem was solved and it is a bit embarrasing that it was caused by code within the application/site.

The problem was a call to "Response.Buffering = false" in Page.OnInit. I'm not sure why this was changed from true to false a while back but I will investigate further. The correct solution would probably be to use Response.Flush() when large contents are sent to the client.

I've seen some related posts about it here:
http://bytes.com/topic/asp-classic/answers/59607-response-buffer-iis-6-0-a (which links to this KB: http://support.microsoft.com/?id=840875)
http://technet.microsoft.com/en-us/library/bb727078.aspx (Tip 14: Use Response Buffering)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.