Microsoft Terminal Server (MS-TS) that uses Remote Desktop Protocol (RDP) and Citrix Metaframe Independent Computing Architecture (ICA) protocols are widely used for local and remote connectivity for PCs and thin clients. The important thing to remember about these types of applications is that they are transferring screen changes over the network. If there are only a few changes, they will require low bandwidth. If there are many changes, they will require high bandwidth.
Another thing is that the traffic in these applications is entirely asymmetric. Downstream traffic takes from tens of Kbps up to several Mbps, while the upstream traffic will be at most several Kbps. When working with these applications, don't forget to design your network according to this.
In this recipe, we will see some typical problems of these applications and how to locate them. For the convenience of writing, we will refer to Microsoft TS; and every time we will write MS-TS, we will refer to all applications in this category, for example, Citrix Metaframe.
When suspecting a slow performance with MS-TS, first check with the user what the problem is. Then, connect the Wireshark to the network, with port mirror to the complaining client or to the server.
For locating a problem when MS-TS is involved, start with going to the users and asking questions. Follow these steps:
- When users complain about a slow network, ask them a simple question: Do they see the slowness in the data presented on the screen, or when they switch between windows?
- If they say that the switch between windows is very fast, it is not an MS-TS problem. MS-TS problems will cause slow window changes, picture freezes, slow scrolling of graphical documents, and so on.
- If they say that they are trying to generate a report (when the software is running over MS-TS) but the report is generated after a long period of time, this is a database problem and not MS-TS or Citrix.
- When a user works with MS-TS over a high-delay communication line and types very quickly, they might experience delays with the characters. This is because MS-TS is transferring window changes, and with high delays these windows changes will be transferred slowly.
- When measuring the communication line with Wireshark:
- Use IO graphs for monitoring the line
- Use filters to monitor the upstream and the downstream directions
- Configure bits per second on the y-axis
- You will get the following screenshot:
- In the preceding screenshot, you can see a typical traffic pattern with high downstream and very low upstream traffic. Notice that the Y-Axis is configured to Bits/Tick. In the time between 485 s and 500 s, you see that the throughput got to the maximum. This is when applications will slowdown and users will start to feel screen freezes, menus that move very slowly, and so on.
- When monitoring MS-TS servers, don't forget that the clients access the server with MS-TS and the servers access the application with another client that is installed on the server. The performance problem can come from the MS-TS or from the application.
- If the problem is an MS-TS problem, it is necessary to figure out if it is a network problem or a system problem:
- Check the network with Wireshark to see if there are any loads. Loads such as the one shown in the previous screenshot can be solved by simply increasing the communication lines.
- Check the server's performance. Applications like MS-TS are mostly memory consuming, so check mostly for memory (RAM) issues.
MS-TS, Citrix Metaframe, and applications simply transfer window changes over the network. From your client (PC with software client or thin client), you connect to the terminal server; and the terminal server runs various clients that are used to connect from it to other servers. In the following screenshot, you can see the principle of terminal server operation:
From the terminal server vendors, you will hear that their applications improve two things. They will say that it improves manageability of clients because you don't have to manage PCs and software for every user—you simply install everything on the server, and if something fails you fix it on the server. They will also say that traffic over the network will be reduced.
Well, I will not get into the first argument. This is not our subject, but I strongly reject the second one. When working with a terminal client, your traffic entirely depends on what you are doing:
- When working with text/characters-based applications, for example, some Enterprise Resource Planning (ERP) screens, you type in and read data. When working with the terminal client, you will connect to the terminal server that will connect to the database server. Depending on the database application you are working with, the terminal server can improve performance significantly or does not improve it at all. We will discuss this in the database section. Here, you can expect a load of tens to hundreds Kbps.
- In cases where you are working with regular office documents such as Word, PowerPoint, and so on, it entirely depends on what you are doing. Working with a simple Word document will require tens to hundreds of Kbps. Working with PowerPoint will require hundreds Kbps to several Mbps, and when you present the PowerPoint file with full screen (function F5) the throughput can jump up to 8 to 10 Mbps.
- Browsing the Internet will take between hundreds of Kbps to several Mbps, depending on what you are doing. High resolution movies over terminal server to the Internet—well, just don't do it.
Before implementing any terminal environment, test it. I once had a software house that wanted their logo (at the top-right corner of the user window) to be very clear and striking. They refreshed it 10 times a second, which caused the 2 Mbps communication line to be blocked. You never know what you don't test.