Conversion: Linux to Windows 2
Question
Does it make sense performance-wise to switch from Red Hat Linux to Windows Server for an A-Shell system which typically has 70 users running programs on it at the same time?
Reply
Given the same hardware, Linux handily outperforms Windows, particularly in larger environments like yours. That said, there are a number of possibly mitigating or extenuating considerations:
1. Windows peer-to-peer should be ruled out of hand for this size system. So we'll assume some kind of server-based model (Windows Terminal Server, Citrix, GoGlobal, ATSD, etc.) for the remainder of the discussion.
Note that these server-based models divide into two completely different categories, what I'll call RDP-style (Windows Terminal Server, Citrix, GoGlobal, etc.) and Telnet-style (ATSD). For the RDP-style (they don't all used RDP specifically, but the concept is the same), the logical screen (within the server) is replicated to the client screen by some pixel-based protocol. As opposed to the Telnet-style case where the server sends characters (bytes) to the client, which is responsible for maintaining its own state and updating the display based on the logic of the character and character-based commands that arrive. The input channel is pretty much the same for the two variations.
2. For RDP-style protocols, you will need a much bigger server than you would for Linux, or for ATSD, because each connection is essentially a full-blown Windows environment on the server. It's not easy to estimate those memory requirements, but as a very rough approximation, I would take the MEMORY partition size specified in miame.ini and add about 10MB per telnet/ATSD connection, and about 50MB per RDP-class connection. That would be for plain text applications. Add another 10-20MB for GUI.
3. In the old days, you'd have to squint very carefully at the previous paragraph. Nowadays, you may just get a server with 16GB RAM and not sweat the details.
4. Likewise for CPU - in the Windows environment, all the display operations are GUI/pixel-oriented (as opposed to byte-oriented in the Linux/ssh environment - even when using ATE for a GUI front end), so it takes a lot more CPU power to update displays. So while a single core Pentium could manage your 70 Linux users, you'd want 8 cores or more for the Windows equivalent. But again, that's no big deal these days, so maybe another meaningless detail not to sweat over.
5. If you go with an RDP-style environment (as opposed to sticking with telnet), you're probably looking at substantial licensing costs. (On the other hand, maybe all those workstations already have client licenses for other reasons, in which case the additional cost may be minimal.)
6. A-Shell GUI operations in the RDP-style environment are actually simpler than in the telnet/ATE environment, because it acts more or less just like the Windows standalone environment. (The AUI layer which converts GUI calls into ATE messages, relays them to the client, and processes the responses, is bypassed. Instead, there is a more seamless screen-replication layer, which may involve more raw bits being transferred, but for many GUI operations is actually more efficient. Plus you eliminate the latency delays involved when an ATE command requires a response from the client.)
7. For plain text applications, the situation is somewhat reversed. ATSD/telnet style communications are generally much more efficient than the RDP-style remote screen replication when it comes to displaying characters. The one exception is scrolling (like in long DIR or TYPE operation) where, in the telnet case, every byte must be transferred, whereas in the RDP case, the scroll may not be as smooth, but it can effectively skip much of the updating by just resynchronizing the display at the end of the scroll. (Admittedly this is a special case, but I do get asked why scrolling displays take longer with byte-oriented telnet than with bit-oriented RDP.)
Fortunately, if you already have a Windows server at the site, which it sounds like you do, you can probably experiment on it without a lot of investment. Particularly if you're leaning towards the Terminal Server approach and already have it installed on another server, just install a demo copy of A-Shell/Windows on it and make an RDP connection to it. You may be able to get a preliminary feel for the performance just by playing with VUE, DIR, and some of the programs in the EXLIB. If you're leaning towards keeping the present telnet clients, you will have to install ATSD, but that isn't very difficult either.
As for version, existing Windows Server installations of A-Shell range from W2000 to W2003 to W2008 to W2012. Although there are plenty of differences in Windows from one version to the next, those differences don't seem to matter much to A-Shell. In fact, if you use the ATSD/TELNET configuration, you don't absolutely need a real "Server" version of Windows; the "professional" version will work. For the relatively large system of 75 users, however, the server versions may provide better environmental support in terms of resource management, security, etc.
Caveat: We have a couple of Windows server sites in the vicinity of 50 users, but yours might well be the biggest ever. In contrast, we have many Linux sites with hundreds of users.
