Also, it seems like a workaround would be to change the IIS connection-timeout to be higher than the FireFox default of 5 minutes. That would ensure that the connections are not closed on the server before FireFox considers them closed. This has implications
regarding server resources, so it isn't ideal... but it may resolve the issue for the time being.
I have seen some issues with that reported on the forums here. It sounds a little flaky. It seems that the network card process for this is not as good at the CPU.
So I presume everyone with the problem has TCP Chimney enabled? It is disabled by default hence why didn't initially think of it. If you had a third party or even OEM build of the server they might have enabled.
It is something that I do not think I will enable at the moment.
Firefox having it's client timeout set of 5 minutes is strange. Why is it so long?
IIS has the longest http keepalive of any web server software at 120 seconds AFAIK the Apache 2 timeout is 15 seconds.
(IMHO the http keepalive timeout is far too long in IIS and hasn't been changed for years. Microsoft's IIS team have a horrible habit of keep all their default values the same version after version of IIS. I need to run some tests on connection of busy servers
to get a better indicatioon of more optimal times.)
So I don't understand the rational for Firefox to have a timeout of 5 minutes. No webserver software will keep there connection open for that long. So why does the cilent do this? What a waste of resources.
I'll post something in that firefox thread/bug reports but it does seem a strange one.
Also, it seems like a workaround would be to change the IIS connection-timeout to be higher than the FireFox default of 5 minutes. That would ensure that the connections are not closed on the server before FireFox considers them closed. This has implications
regarding server resources, so it isn't ideal... but it may resolve the issue for the time being.
Yeah that should work. It was something I hinted at before in a previous post. It is no huge deal having increased http keep alives it will just have the slight overhead of more connections being open.
Well, if the TCP Chimney is disabled by default, that would explain why the suggested changes did absolutely nothing. The registry values they had me add didn't exist to begin with, so I was doubtful adding a value of false would change much.
I'll try increasing the connection timeout to 300 and see what that does.
I did not enable TCP Chimney, and I do not have any registry settings mentioning it either. It'll be interesting to see what the support staff suggest to try next...
I made the change to 300 secs on my IIS7 boxes and I can't reproduce the issue, so it seems like that is an effective workaround for those troubled by this issue. Hopefully you have the same experience.
I also mentioned to the FireFox team that they should consider changing that default timeout as it makes no sense to have such a large default value. If FF didn't have such a large timeout this issue wouldn't even be a problem to begin with!
Thanks a ton to VorlonShadow and pbreitz for helping to diagnose this incredibly frustrating problem!
Actually, before I go increasing the connection timeout, I'm curious what people think would be better:
Increase the connection timeout
Disable HTTP keep-alive
In theory these should both have an effect, right? Obviously they're each going to have their own impact on server resources, but which would be better for a site of modest traffic (approx 2000 visitors & 7000 pageviews / day).
I suppose the higher the pageview/visitor ratio, the more effective a higher connection timeout would be, and vice versa. But I just have no idea what scalar values to attach to each method for purposes of comparing server load.
From a user-impact perspective I would go with increasing the connection-timeout. If you disable keep-alives altogether then the browsers will have to make tons more connections to your website for each request (resulting in slower page load times and most
likely a visible performance decrease for your users). Having a higher timeout just means you'll have a bunch of dead connections hanging around on your server waiting for their 5-minute lifespan to tick away. I would vote for trying the increased timeouts
first, and then move to disabling keep-alives as a last resort if you run into some major issue.
Thanks ianderson, I've bumped up the connection timeout on a few dev sites and one production site to test things out. Hopefully I'll have the same experience as you.
One thing to keep in mind... if you have a load-balancer in between your server and your clients, you'll need to ensure that the balancer has a "sticky" connection timeout of 5 minutes as well. If the load-balancer swaps between two active servers within
the 5-minute timeout of FF, then you'll see the same issue.
ianderson
22 Posts
Re: Pages appear to stop responding
May 11, 2009 04:26 PM|LINK
Also, it seems like a workaround would be to change the IIS connection-timeout to be higher than the FireFox default of 5 minutes. That would ensure that the connections are not closed on the server before FireFox considers them closed. This has implications regarding server resources, so it isn't ideal... but it may resolve the issue for the time being.
Rovastar
3321 Posts
MVP
Moderator
Re: Pages appear to stop responding
May 12, 2009 08:26 AM|LINK
pbreitz
Aha the TCP Chimney.
I have seen some issues with that reported on the forums here. It sounds a little flaky. It seems that the network card process for this is not as good at the CPU.
So I presume everyone with the problem has TCP Chimney enabled? It is disabled by default hence why didn't initially think of it. If you had a third party or even OEM build of the server they might have enabled.
It is something that I do not think I will enable at the moment.
Firefox having it's client timeout set of 5 minutes is strange. Why is it so long?
IIS has the longest http keepalive of any web server software at 120 seconds AFAIK the Apache 2 timeout is 15 seconds.
(IMHO the http keepalive timeout is far too long in IIS and hasn't been changed for years. Microsoft's IIS team have a horrible habit of keep all their default values the same version after version of IIS. I need to run some tests on connection of busy servers to get a better indicatioon of more optimal times.)
So I don't understand the rational for Firefox to have a timeout of 5 minutes. No webserver software will keep there connection open for that long. So why does the cilent do this? What a waste of resources.
I'll post something in that firefox thread/bug reports but it does seem a strange one.
Rovastar
3321 Posts
MVP
Moderator
Re: Pages appear to stop responding
May 12, 2009 08:28 AM|LINK
Yeah that should work. It was something I hinted at before in a previous post. It is no huge deal having increased http keep alives it will just have the slight overhead of more connections being open.
Rovastar
3321 Posts
MVP
Moderator
Re: Pages appear to stop responding
May 12, 2009 08:31 AM|LINK
More on the headaches of the TCP chimney
http://blogs.technet.com/networking/archive/2008/11/14/the-effect-of-tcp-chimney-offload-on-viewing-network-traffic.aspx
pbreitz
8 Posts
Re: Pages appear to stop responding
May 12, 2009 12:48 PM|LINK
Well, if the TCP Chimney is disabled by default, that would explain why the suggested changes did absolutely nothing. The registry values they had me add didn't exist to begin with, so I was doubtful adding a value of false would change much.
I'll try increasing the connection timeout to 300 and see what that does.
ianderson
22 Posts
Re: Pages appear to stop responding
May 12, 2009 12:59 PM|LINK
I did not enable TCP Chimney, and I do not have any registry settings mentioning it either. It'll be interesting to see what the support staff suggest to try next...
I made the change to 300 secs on my IIS7 boxes and I can't reproduce the issue, so it seems like that is an effective workaround for those troubled by this issue. Hopefully you have the same experience.
I also mentioned to the FireFox team that they should consider changing that default timeout as it makes no sense to have such a large default value. If FF didn't have such a large timeout this issue wouldn't even be a problem to begin with!
Thanks a ton to VorlonShadow and pbreitz for helping to diagnose this incredibly frustrating problem!
pbreitz
8 Posts
Re: Pages appear to stop responding
May 12, 2009 01:01 PM|LINK
Actually, before I go increasing the connection timeout, I'm curious what people think would be better:
In theory these should both have an effect, right? Obviously they're each going to have their own impact on server resources, but which would be better for a site of modest traffic (approx 2000 visitors & 7000 pageviews / day).
I suppose the higher the pageview/visitor ratio, the more effective a higher connection timeout would be, and vice versa. But I just have no idea what scalar values to attach to each method for purposes of comparing server load.
Any thoughts?
ianderson
22 Posts
Re: Pages appear to stop responding
May 12, 2009 01:06 PM|LINK
From a user-impact perspective I would go with increasing the connection-timeout. If you disable keep-alives altogether then the browsers will have to make tons more connections to your website for each request (resulting in slower page load times and most likely a visible performance decrease for your users). Having a higher timeout just means you'll have a bunch of dead connections hanging around on your server waiting for their 5-minute lifespan to tick away. I would vote for trying the increased timeouts first, and then move to disabling keep-alives as a last resort if you run into some major issue.
pbreitz
8 Posts
Re: Pages appear to stop responding
May 12, 2009 01:10 PM|LINK
Thanks ianderson, I've bumped up the connection timeout on a few dev sites and one production site to test things out. Hopefully I'll have the same experience as you.
ianderson
22 Posts
Re: Pages appear to stop responding
May 12, 2009 01:13 PM|LINK
One thing to keep in mind... if you have a load-balancer in between your server and your clients, you'll need to ensure that the balancer has a "sticky" connection timeout of 5 minutes as well. If the load-balancer swaps between two active servers within the 5-minute timeout of FF, then you'll see the same issue.