Poor performance on SharePoint site (IE6, Proxy, Windows Auth)

Question

This is a very strange issue I am having.

My client is experiencing poor performance (20 sec per page load or so) when accessing their SharePoint 2007 site that is hosted somewhere externally by a hosting provider. In fact it is not just that particular SharePoint site - we tried accessing another SharePoint site that is online and we were experiencing the same performance issues.

Now it is ONLY slow if ALL of these conditions are true:

1. User is using IE6
2. User is using a machine connected to the client's company network (there's a proxy Configured)
3. User is authenticated (Windows Authentication)

So to back these theories up:

1. We have tested with FireFox and IE 8 from within the company network and it's performing well (both authenticated as well as unauthenticated).
2. We have tested with IE6 from a machine that's not on the client's company network and it's performing well (both authenticated as well as unauthenticated).
3. We have connected to an online WSS team site (out of the box) that is open to anonymous users with IE6 using a machine that's connected to the client's company network and it's performing well.

Some other interesting facts:

1. Accessing over HTTPS or HTTP doesn't seem to make any difference
2. The client has another SharePoint system (based on SP2003 and requiring Windows Auth) which is hosted internally (so not going through the proxy), which is performing just fine.
3. Client's internet connection is just fine for all other sites
4. To make it even weirder, the mobile view (add "/m" to subsite url) seems to be performing fine! Though I think it's just because these pages are just so tiny.

I get the impression that is has something to do with the way IE6 handles Windows Authentication in combination with the proxy used in the client's company network. Does that make any sense? I'm a developer so it could well be that I am talking rubbish here :)

Ideas anyone?

Answer 1

This is not really an "answer" but the comments field is too small :)

Sounds to me like there could be something wrong with the way in which the proxy holds onto authentication tokens when dealing with IE6? Or maybe I am talking rubbish too :) anyway, I have had "similar" issues like this before but specifically when using Kerberos authentication throughout - turned out the proxy was misconfigured and was defaulting the request to NTLM (which requires round trips to the DC to authenticate each and every request - hence the slow down!).

Anyway, thats not very related. The resolution we had was to call in Microsoft - but all they did was install Network Monitor onto each server in the request chain (http://www.microsoft.com/downloads/details.aspx?FamilyID=983b941d-06cb-4658-b7f6-3088333d062f&displaylang=en) and start a trace, perform a page request and then see where the pause (or in our case a loop of identical requests) takes place, this should then give you a better idea of where the problem truly lies. Only problem with this method, is you need to be able to install network monitor on the client, proxy server and moss server and start tracing all at the same time!

Answer 2

Network guys have resolved the problem; I have been told the following:

It turned out to be a DNS problem.

Apparently there was some legacy network configuration that would force clients to use an internal DNS for this particular domainname and this DNS was not capable of resolving the IP address for this web site properly (not sure exactly how/what/why).

Additional problems noticed were centred around authentication requests and re-authentication requests from the site and the proxy server.

To backup the above theory: the act of adding a hosts file entry on the client fixes the problem.

I still don't understand why it's only IE6 though...

Answer 3

Your analysis was correct. There is a problem with IE6 and windows authentication against IIS 6.0.

This problem occurs because the Internet Explorer 6 client regularly resets the TCP connections

See http://support.microsoft.com/kb/922703 for how to get around it.