Terminal Services Performance

[Bubbalouie]

I'm exasperated. I hope someone can point me in the right direction.

I deployed a Windows Terminal Services server to support two applications at our central site that are now acccessed from a remote location that I'll refer to as Trouble1.

I told management it would not be as fast as it is at our central site. Users are complaining loudly to my bosses about response time and I need to find some type of metric.

My central site hosts 9 vpn's that connect to PIX 506e. Only Trouble1 accesses these two apps, the other 8 locations hit another application.

The central site has a load balanced T1x2 connection. Trouble1 has a bonded T1x2 connection.

Central site generally has about 50% of it's bandwidth in use during the day, but depending on what is going on at the 9 remote sites that fluctuates for short periods of time up to the 70 to 80 percentile. I've been there when this happens and it generally lasts for a few minutes and manifests itself with a delay of up to 30 seconds between typing a character and the character showing on the screen. It's usually like a minute maybe 3 but very rarely as much as 10 minutes.

I understand that the users are frustrated by the delay, but they aren't working overtime to make up for it.

Is there a formula or general guide I can use to determine whether I need to add additional bandwidth or tell management to tell people to deal with it? I hate to just throw more bandwidth at the problem.

I know that's kinda vague and every situation is different, but if anyone has ever had to deal with users complaining about slow response times and how you determined whether their complaints were 'valid' or not, I'd sure appreciate hearing your story.

 

[Roadki11]

Couple of questions and or suggestions. How many users connected at a time? Try reducing the encryption level, this should reduce over head. Reduce resolution to no more than 1024 x 768, again to reduce over head. Dont allow any extra curricular back ground connections if you can, like local drive, printer, sound, ect mapping. Reduce video quality to no more than 15 bits. Tweeking this stuff should show marked improvement in response time.

RoadKi11

"This apparent fear reaction is typical, rather than try to solve technical problems technically, policy solutions are often chosen." - Fred Cohen

 

[SteveRoadWarrior]

You're not going to like my answer.

If I were in their shoes, I'd be complaining too. 10-30 second delays on a regular basis for typing is horrible. Just imagine trying to use a mouse under those conditions.

Our users complain if they see two letters show up on the screen at the same time while typing.

How much data do you think it takes to make that letter appear on the screen? A few K? So if you have plenty of bandwidth, then what's the problem? Latency is the problem.

During these periods of high utilization, what are your ping times? Don't know? Get a free tool like PRTG Network Monitor and keep track. If your users are always getting below 30ms, then Latency isn't your problem. Here's a handy chart (completely my opinion and completely off hand):

First of all, you shouldn't have spikes over 500ms. That's trouble.

> 40 ms should be fine
40-80 ms is noticeable but few people will complain
80-200 ms is poor on a regular basis, but acceptable on occasion
200-400 ms is unacceptable but users may overlook it if it only happens for a few minutes a day
400-800 ms is unacceptable but users will overlook it if it happens during a company party.

If you have periods of latency over 3000 ms, then you're clearly running Satellite Internet, not a T1. But let's assume you really have a T1.

Well, what can cause this sort of T1 logjam? Here's the answer you don't want to hear: It's problably legitimate work related traffic. You probably already looked for the YouTube addicted users, and the BitTorrent users. So what's left? Email, Printing, Domain Login, User Profiles, AD sync, DFS, Backup Operations... they all take huge amounts of bandwidth. And they're all important, but not as important as the Terminal Server data... small as it may be in size it REALLY needs to get prioritzed over the other traffic.

Look up some info on QoS and configure your routers, pay the extra few bucks a month to get your ISP to help prioritize your T1 ingress points so that Terminal Server bandwidth get's the first shot at the T1 time. It's all about time, not bandwidth.

In case it's your servers, read up on these links:

http://www.brianmadden.com/blogs/brianmadden/archive/2003/08/21/citrix-

metaframe-and-microsoft-terminal-server-performance-optimization-
and-tuning.aspx

http://www.brianmadden.com/blogs/brianmadden/archive/2004/12/20/terminal-

server-and-citrix-metaframe-network-performance-troubleshooting-part-1-
of-2.aspx

http://www.brianmadden.com/blogs

/terminal_services_for_microsoft_windows_server_2003_advanced_technical_des
ign_guide/pages/monitoring-your-terminal-servers.aspx

 

[itsp1965]

As mentioned above you have to take into consideration the number of users accessing your app/server via TS. An old formula used to be that TS needs requires a minimum of 20Kb/s per user. If you have 50 users running simultaneously you have already saturated a T1 link

I had similar issues with remote sites with latent links, throwing more bandwidth at it won't help as users will find a way to use that up also. I would consider using some kind QoS service on your routers or deploy a WAN acceleration device (like a packetshaper). This will enable you to prioritize your traffic by giving a higher priority to TS traffic as opposed let's say web surfing.

 

[Bubbalouie]

OK, I've been watching it for about 5 hours now. Average ping response is 111 ms which put's it in the bad range.

The RDP traffic is passing back to the central site in site-to-site vpn's. I'm guessing I need to prioritize the vpn traffic and not the RDP traffic because of that.

I have managed routers(cisco 2811's) from ATT. Can I just tell them to prioritize VPN traffic?

Thanks!

 

[SteveRoadWarrior]

Yes, if you tell them to prioritize the VPN traffic it may help... provided that the other traffic contending for that resource is Internet based.

If the other traffic which is fighting for the T1 is also headed to the main office, like file sharing or printing traffic, then you'll only spend IT dollars without getting a good return.

Ask your router management team to tag the packets at both ends of the VPN tunnel, key off of source and destination port (destination 3389 for RDP headed from the remote site, source 3389 for RDP headed to the remote site). Once those packets are tagged, then QoS can be enabled.

Enable QoS and tell the routers to highly prioritize traffic which is tagged over traffic which is not tagged.

This is complex and requires testing and the understanding of your users. Or you could take those same IT dollars and take itsp1965's suggestion of buying a pair of traffic shaping devices. Put them into the flow in transparent mode and see if that helps. Besides, you'll probably get the added benefit of extra network monitoring so you can tell the bosses where their IT infrastructure dollars are going (Facebook, Youtube, etc).