Overall Sluggishness Lack of Responsiveness

Overall Sluggishness & Lack of Responsiveness

This chapter has previously focused on the idea that overall sluggishness of your Terminal Servers could be related to having too many users on a server. However, it's often the case that only some of your users will experience sluggish sessions while others will not. In these cases the issue can usually be traced back to poor network performance. Before we explore the details of how you can tune your network, it's important to review some basics of network performance.

Understanding Factors that Affect Network Performance

When considering network performance, you need to understand the difference between "latency" and "bandwidth." Both are used to describe the speed of a network. Bandwidth describes how much data can pass through the network in a given period of time, such as 10 megabits per second, or 256 kilobits per second. Latency describes the length of time, usually expressed in milliseconds (there are 1000 milliseconds in one second), that it takes for data to get from point A to point B. Bandwidth and latency are independent of each other.

The fact that bandwidth and latency are different from each other is an important concept to understand in Terminal Server environments. (This is so important that it calls for another analogy.)

Imagine that each packet of data is an automobile, and the network is a highway. In order for the data to get from point A to point B, an automobile would have to travel from one end of the highway to the other. In high-bandwidth environments, the highway has many lanes, and hundreds of automobiles can be on it at the same time. In low bandwidth environments, the highway is a narrow country road, and only a few automobiles can fit on it at the same time. The width of the highway is like the bandwidth of the network. Since latency affects how long it takes data to traverse the network, the speed of the automobiles on the highway represents the latency. Even on narrow highways (low bandwidth), there might be people who drive really fast and travel the road quickly (low latency). Conversely, even if you have a large number of automobiles on a wide highway (high bandwidth), the drivers may choose to drive slowly (high latency).

Bandwidth and latency are independent of each other because the width of the highway does not directly affect how fast you drive on it. However, as you've probably guessed by now, it's possible that bandwidth can affect latency.

Now imagine a low-bandwidth environment that also has low latency (a narrow highway where the people drive really fast). If there are only a few automobiles on the road, they can go fast without a problem. However, imagine that the highway begins to fill up with more and more autos. Even though the people want to drive fast, they can't because the highway is too crowded. The effect is that it will take longer for automobiles to get from one end of the highway to the other. In a sense, the latency has increased from low latency to high latency simply because there are too many vehicles on the highway.

There are several solutions to the overcrowded highway problem. You could:

• Widen the highway.

• Remove some of the vehicles.

• Force people to drive smaller vehicles.

• Install traffic signals and lane control devices to manage the traffic.

• Just tell people to "get used to it."

As you'll see, the potential solutions to the overcrowded highway problem are also the potential solutions to overcrowded networks in Terminal Server environments.

A network connection's bandwidth and latency each affect Microsoft RDP session traffic in different ways:

Bandwidth affects how much data the session can contain. Higher resolution sessions require more bandwidth than lower resolution sessions. Sessions with sound, printing, and client drive mapping all require more bandwidth than sessions without. If a particular session only has 15Kbps of bandwidth available, that session can still have decent performance so long as the resolution, color depth, and other virtual channel options are tuned appropriately.

Latency is usually more critical in Terminal Server environments. Since latency affects the amount of time it takes for communication to pass between the client and the server, environments with high latency can seem like they have a "delay" from the user's perception.

For example, imagine an environment in which a user was using Microsoft Word via a remote RDP session. When they press a key on their client device, the key code is sent across the network to the Terminal Server. The server processes the keystroke and prepares to display the proper character on the screen.

Because this is a Terminal Server, the screen information is redirected back across the network where it is displayed on the local client device. In order for a character to appear on the screen, data must travel from the client to the server and then from the server back to the client again.

In this situation, if the latency of the network is 10ms, the network delay will only add 20ms (because the data crosses the network twice) to the time between the key press and the character appearing on the user's screen. Since 20ms is only 0.02 seconds, the delay will not be noticeable. However, if the latency was 200ms, the total delay to the user would be 400ms, or almost one-half of a second. This length of delay would be noticeable to the user and would probably be unacceptable.

An easy way to get an approximation of the latency in your environment is to perform a TCP/IP ping. You can ping the server from the client or the client from the server, it doesn't matter which way. For example, if your server is called "server01," you would execute the following command from a client workstation:

ping server01

(Be sure that you execute the ping command locally on the workstation, not via an RDP session on the server.) The results will look something like this:

 Pinging server01 [10.1.1.42] with 32 bytes of data: Reply from 10.1.1.42: bytes=32 time=378ms TTL=118 Reply from 10.1.1.42: bytes=32 time=370ms TTL=118 Reply from 10.1.1.42: bytes=32 time=360ms TTL=118 Reply from 10.1.1.42: bytes=32 time=351ms TTL=118 Ping statistics for 10.1.1.42: Packets: Sent = 4, Received = 4, Lost = 0 Approximate round trip times in milli-seconds: Minimum = 351ms, Maximum = 378ms, Average = 364ms 

Notice that the "time=" section of each line shows you the approximate latency. This time is the time that the "pinger" waited for a response from the "pingee," meaning that the time shown represents the entire round-trip. The above scenario with the 364ms latency could have occurred in a dial-up environment with a bandwidth of 28kbps or a frame-relay environment with 512kbps. In either situation, the performance would not be as good as in an environment with less latency.

Resolving Network Bandwidth Issues

Once you've determined whether your network performance issues are bandwidth-related or latency-related, you can begin to address them. If your network suffers from a lack of bandwidth:

• Install a hardware device to monitor and control applications and bandwidth. This is like adding a traffic cop and traffic signals in our highway example.

• See what type of traffic you can remove from the network. This is like removing extra automobiles in our highway example.

• Make the RDP sessions as "small" as possible. This is like convincing everyone to drive smaller cars.

Let's take a look at how you could implement each one of these three solutions.

Hardware Network Bandwidth Shapers

The most popular types of bandwidth management devices in Terminal Server environments are Packeteer's PacketShaper (www.packeteer.com), Sitara's QoSWorks (www.sitaranetworks.com), and Allot Communications' NetEnforcer (www.allot.com). Both are physical hardware devices that sit between your network and the WAN router as shown in Figure 13.3.

Figure 13.3: Bandwidth shaping hardware

These devices allow you to analyze and capture current traffic usage (which is when you'll discover that 75% of your WAN traffic is web surfing). You can then give Microsoft RDP traffic priority over other types of traffic. You can even configure these devices to give different priorities to different IP addresses. You can also guarantee certain amounts of bandwidth to RDP (or any protocol).

These third-party devices are similar to Cisco Quality of Service (QoS) devices, except that the Sitara and Packeteer devices are "Layer 7" routers and can differentiate RDP traffic from other types of traffic.

Removing Traffic

One of the easiest things you can do to free up bandwidth for your RDP sessions is to remove as much non-Terminal Server traffic as possible. Are you backing up data across the network? Are your users downloading MP3s? All of this takes bandwidth away from RDP sessions.

Squeezing RDP

Once you've removed any unnecessary traffic from your network, you can start to think about squeezing the RDP protocol down as small as possible. There are several steps that you can take to do this:

• First, turn off as much desktop "glitz" as possible. This means disabling wallpapers, menu animations, and desktop themes.

• Next, disable any RDP virtual channels that you're not using, such as printing or local drive access.

• You should also configure the users' sessions so that they're using the minimally required settings, such as the lowest resolution and color depth needed.

• If you haven't done so yet, be sure that your Terminal Servers are running the most recent versions of service packs and hotfixes.