HTTPS connections slow

  • Thread starter Thread starter T OPry
  • Start date Start date
T

T OPry

While I don't think this is unique/specific to TS, I am experiencing this
problem only on ONE Terminal Server (we have 3). No workstation has the
issue. All systems on same domain, same GPO, same everything (policy,
security, firewall, proxy wise).

W2k3 Server SP2 running IE6 all latest patches

The problem is this:
Using IE - browsing to any HTTP website, response is immediate. Navigate to
ANY HTTPS site and its glacially slow - 30+ seconds for a page to
load/display. This is on ANY external HTTPS site. (we only have one host
internally that uses HTTPS for authentication, so its not much of a test).

What I have tried: putting the site in the Trusted or Intranet site,
lowering security to the absolutely lowest, setting every option I can think
of in IE - all to no avail. (also turned of A/V service and any other
process/service that was not essential). I have tested when I was the only
user/session on the system and when there were 30 - same lag. I have
bypassed the proxy (though no other system using the proxy has this issue) -
so as best I can tell, it is something to do with IE or the OS itself. I
have tried setting the TCPWindowSize regkey (though no other TS has this key
nor problem).
Not a DNS response issue (all systems on LAN use same DNS).

After typing in the URL and pressing enter - IE appears non-responsive and
nothing displays for 30+ seconds. Task Manager shows a second instance of IE
(even though one has not been launched and then shows IE is 'non-responsive'
and still shows the prior (HTTP) site in the task list. After 15-20 seconds,
Task Manager shows IE as running, again shows but one instantce and in 10 or
so more seconds, the site name appears and finally the page displays. After
I go to an HTTPS page, if I do not close IE, I can navigate back to it
(either through the back button or typing in the url) and that page will
appear in about 5 seconds. Still slow, but much better. Go to a page within
the site that isn't cached and its back to 30+ seconds. The option to clear
the cache when IE closed is set via GPO - but it is on all systems.
Unchecking that option does NOT make a difference.

This has been happening for some time, since I rarely use this TS for
browsing, I did not notice until a user mentioned it. It may have been
related to one of the many patches, but with the delay in discovering it,
that's impossible to tell.

Any suggestions on what it may be or how to diagnose the issue would be
appreciated.
 
(cross-post added to Windows Terminal Services)
T OPry said:
While I don't think this is unique/specific to TS, I am experiencing this
problem only on ONE Terminal Server (we have 3). No workstation has the
issue. All systems on same domain, same GPO, same everything (policy,
security, firewall, proxy wise).

W2k3 Server SP2 running IE6 all latest patches

The problem is this:
Using IE - browsing to any HTTP website, response is immediate. Navigate to
ANY HTTPS site and its glacially slow - 30+ seconds for a page to
load/display. This is on ANY external HTTPS site. (we only have one host
internally that uses HTTPS for authentication, so its not much of a test).

What I have tried: putting the site in the Trusted or Intranet site,
lowering security to the absolutely lowest, setting every option I can think
of in IE - all to no avail. (also turned of A/V service and any other
process/service that was not essential). I have tested when I was the only
user/session on the system and when there were 30 - same lag. I have
bypassed the proxy (though no other system using the proxy has this issue) -
so as best I can tell, it is something to do with IE or the OS itself. I
have tried setting the TCPWindowSize regkey (though no other TS has this key
nor problem).
Not a DNS response issue (all systems on LAN use same DNS).

After typing in the URL and pressing enter - IE appears non-responsive and
nothing displays for 30+ seconds. Task Manager shows a second instance of IE
(even though one has not been launched and then shows IE is 'non-responsive'
and still shows the prior (HTTP) site in the task list. After 15-20 seconds,
Task Manager shows IE as running, again shows but one instantce and in 10 or
so more seconds, the site name appears and finally the page displays. After
I go to an HTTPS page, if I do not close IE, I can navigate back to it
(either through the back button or typing in the url) and that page will
appear in about 5 seconds. Still slow, but much better. Go to a page within
the site that isn't cached and its back to 30+ seconds. The option to clear
the cache when IE closed is set via GPO - but it is on all systems.
Unchecking that option does NOT make a difference.

This has been happening for some time, since I rarely use this TS for
browsing, I did not notice until a user mentioned it. It may have been
related to one of the many patches, but with the delay in discovering it,
that's impossible to tell.

Any suggestions on what it may be or how to diagnose the issue would be
appreciated.
Click to expand...



I'm not clear if this is a client issue or a server issue.
Probably with no diagnostics there's fingerpointing going on?
For a client issue I would try using FiddlerTool + RPASpy
just to see what is going on "under the covers".
Then the client should be able to refine its symptom description
to something concrete.

Hmm... that won't be as useful as I thought. There's no timestamp
in FiddlerTool. ; ] To get more precise diagnostics timewise then
you could use netcap and Ethereal. Unfortunately the https will
make it difficult to know anything more about each piece. There is
supposedly a way to activate more trace data for at least some https
sessions but I haven't had much luck with it.
Keyword for searching: winhttptracecfg

BTW this is slightly off-topic for IE6 Browser.
You may have more luck posting in an OS-specific newsgroup.
E.g. since you are using OE as your newsreader
you could try pressing Ctrl-w and typing c.w term
to see some. In fact, since I'm curious to know if I'm
on the right track I'm cross-posting to the one which
seems to be the most general.


Good luck

Robert Aldwinckle
---
 
Back
Top