One issue to consider when setting up a Thin Client system is the size of the Server. Since all of the applications will be running on this machine, it is vital that it be big enough – but since cost is always a factor it is important that it not be unnecessarily oversized. Like the dilemmas faced by Goldilocks, the correct server is not too big, not too small, but just right.
In a discussion about server sizing, Microsoft makes the following statement:
“In general, processor and memory requirements scale linearly: You can support double the number of users on a multiprocessor-capable system by doubling the number of processors and doubling the amount of memory. For this reason, purchasing a system that supports multiple processors, even if you initially purchase only one processor, allows you to add capacity easily as your requirements grow.”
This is a good start, but leaves a great deal of leeway, and a little additional discussion is in order.
Server Size Depends on the Application
It is easy to classify computer users according to the demands that they place on the server, and for the purpose of this article we will break the user space up into two groups – Industrial and Commercial.
Industrial Users
The typical industrial user is a special case, and therefore does not fit into the sizing requirements usually advertised by Microsoft. Some of the factors associated with most industrial applications that may make them unique:
One (big) program – Most HMI programs are much larger than the smaller applications run daily by commercial users. Some do have special versions for display only nodes or even Terminal Services, but these seem to be the exception.
Constant use – The industrial application is typically up 24 hours a day, and so every industrial Thin Client on the network should be counted on to add one application on the server. This is different than the commercial user, where probably one out of every five clients are not running any programs.
Mostly idle / Highly computational – While the program is probably running 24/7, the system requirements will possibly vacillate wildly. One display screen may simply show a few rarely changing production totals; while another screen in the same application may show 500 data points that all have to be calculated from continuous data. This requires the system planner to assume the worst when sizing the server. And the size of the screens being displayed may have a huge impact on the amount of RAM required.
Maybe DOS? – Some industrial applications still require DOS, and you might have another problem: keyboard polling. Since they’re designed for a single-tasking environment, some DOS applications poll the keyboard for input so that they can respond as quickly as possible. Doing this uses up a lot of CPU cycles.
With industrial applications, the best way to pin down the correct server size is, unfortunately, to run the application. Performance varies drastically depending on the type of HMI, the number of ‘tags’, and the requirements of the display and alarming system. Find a PC running the program and screens that will be run on the Thin Client, and discover the system resources being consumed. If you can get an idea of the RAM and processor loading, and compare it to the system when the application is not loaded, you will have a pretty good idea of what to expect. Assume the RAM will scale linearly, and then make an estimate of the CPU cycles needed.
Commercial Users
These “office type” people are generally light users, and typically run a single application at a time (word processing, Excel, etc.). If they do have two or more programs running simultaneously, they do not frequently switch between programs. These applications do not place high data-processing demands on the system, and a large part of the time the computer is basically idle.
An advantage that most of the office type applications (especially Microsoft) have is that they are running applications that allow the Terminal Server to share executable resources between the individual users, just as Windows shares executable resources (.dll, .exe, and so on) between individual programs. As a result, the memory requirements for additional users running the same program are typically less than the requirements for the first user to load the application.
The problem is that the number of users that a single server can support depends heavily on a number of factors, many of which vary over time, and the range is pretty dramatic.
If you want to be safe, you might want to go ahead and “super size” that server order. If you put down a little more money in a server up front, you will probably end up saving money later on down the line.
