What to Expect From the Windows Terminal Services in a 64-Bit Environment (Part 2)

If you missed the previous article in this series please read What to Expect From the Windows Terminal Services in a 64-Bit Environment (Part 1).

In Part 1 of this article series, I explained that one of the most frustrating aspects of administering a Terminal Server environment is the fact that relatively few user sessions can sometimes max out a terminal server’s capabilities. I then went on to explain that one technology that is promising to help to limit the impact of user sessions is the gradual shift to 64-bit computing. In this article, I will continue my discussion by talking about the impact of a shift to a 64-bit operating system on your server’s hardware.

The CPU

In the previous article in the series, I explained several reasons why upgrading your terminal server to a 64-bit operating system could allow the server to run more efficiently, and support more users in the process. Although everything that I said in Part 1 is true, there are situations in which making the move to a 64-bit operating system can actually degrade the server’s performance. In most cases, making the move to a 64-bit environment will help performance, but I feel I need to explain why going to a 64-bit environment can occasionally hurt the server’s performance.

As you probably know, Intel and AMD both manufacture processors that will work with either 32-bit or 64-bit (X64) versions of Windows. Imagine for a moment that your server has such a processor, but is currently running the 32-bit version of Windows Server 2003 and is hosting a set of 32-bit applications through the Terminal Services. Now imagine that your server’s CPU is being maxed out by user sessions, so you decide to upgrade the server to the X64 version of Windows Server 2003. After the upgrade, your server will likely be able to support even fewer user sessions than it was previously able to.

Part of the reason for this is that the server is running 32-bit applications. Because the server is running a 64-bit operating system, it has to emulate a 32-bit environment in order for the 32-bit applications to run. This emulation is handled by the WOW64 (Windows on Windows 64) emulation layer. Technically speaking, in the X64 version of Windows, WOW64 works more like a translation layer than an emulation layer, but that’s beside the point. The point is that there is now additional overhead being placed on the system, just to make the applications run. Typically, the WOW64 layer increases CPU consumption by less than 10%. Even so, if the CPU is already being used to its maximum capacity, any additional overhead would limit the number of user sessions that the server can support.

Another reason why the CPU won’t be as efficient after the upgrade to a 64-bit operating system is because the 64-bit operating system places a higher demand on the CPU. Various data structures, such as data pointers, are twice as large when a 64-bit operating system is being used as when a 32-bit operating system is in use. This means that the memory access footprint size is increased and the cache efficiency is proportionately decreased.

Memory

Another resource that you will definitely have to consider is RAM. If you are thinking about upgrading a terminal server to use a 64-bit operating system, the server will likely need a lot more memory than what it has now. The actual amount of additional memory that will be required varies widely depending on the way that users are using the server and on the applications being run on the server. However, Microsoft recommends increasing the server’s RAM by fifty to one hundred percent (assuming that the server has adequate RAM while running a 32-bit operating system).

In a recent Microsoft benchmark test, a terminal server with 280 active users was using about 5 GB of RAM while running a 32-bit operating system. When the system was upgraded to a 64-bit operating system, the same user load consumed about 66% more memory (8.3 GB). There was also an over 100% increase in the amount of committed memory in use. The 32-bit operating system used 15 GB of committed memory, while the 64-bit operating system used 35 GB. Keep in mind though that these benchmark tests were not intended to stress the server, and therefore the memory manager did not trim the working set. Therefore, a real life deployment may require even more memory.

Disk

Although any component in a system can be a bottleneck, the bottleneck in 32-bit terminal servers is often the CPU. In the X64 version of Windows Server 2003 though, the operating system is designed to take full advantage of multi-core processors. As such, the system bottleneck often shifts from the processor to the disk subsystem for 64-bit, multi-core servers supporting high numbers of user sessions.

If you upgrade a terminal server from a 32-bit operating system to a 64-bit operating system, you probably aren’t going to find that your disk requirements differ that much from what they are now. One notable exception is that the necessary increase in the server’s memory also dictates an increase in the server’s pagefile size, which could potentially cause you to have to make some changes to your disk sub system. Aside from that though, there are no major issues that would render your current disk subsystem ineffective after an upgrade.

This doesn’t mean that you should ignore your server’s disk subsystem though. As I mentioned earlier, increased processor efficiency (related to the way that Windows uses multiple core processors) could cause the disk subsystem to become a bottleneck as the number of user sessions increases. This is particularly a concern for those who may be consolidating multiple 32-bit servers onto a single 64-bit server.

One step that you can take to avoid having a disk subsystem bottleneck is to use higher numbers of smaller hard drives as opposed to fewer numbers of larger drives. For example, three 500 GB drives would give you the same amount of space as five, 300 GB drives. Assuming that all things were equal, the array with the five drives would deliver better performance than the array with three drives.

Another way to mitigate a possible disk bottleneck is to increase the amount of RAM in the server. The more memory the server has, the more disk reads can be cached. This dramatically increases performance because the disk subsystem will not have to be accessed as often. However, to achieve the desired effect, the server will require significantly more RAM than what is required by the operating system and the user sessions.

One last thing that you can do to help prevent a disk bottleneck is to use a make use of a battery backed caching controller for your direct attached storage. This will allow you to take advantage of write back caching while protecting writes that have not yet been committed to disk.

Conclusion

As you can see, it’s a bad idea to just blindly install a 64-bit operating system onto an existing terminal server. Installing a 64-bit operating system has major implications from a hardware standpoint. In this article, I have discussed some of the most notable impacts that a 64-bit upgrade will have on your hardware.

If you missed the previous article in this series please read What to Expect From the Windows Terminal Services in a 64-Bit Environment (Part 1).

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top