Performance in Large Systems

Added February 2018

A reseller says: "My client has approximately 250 users, wants to migrate to A-Shell, and can create—through virtualization—pretty much any environment and operating system. What environment—Windows or Linux—should I recommend to the client for best performance, and why?" Our response follows.

In our experience, the limiting factor in overall system performance for typical A-Shell systems is disk I/O, which is dependent on a combination of factors including the physical performance of the disk hardware, cache performance, latency/bandwidth between the disk and the user memory, and locking performance.

The worst architecture is Windows P2P (peer-to-peer) LAN, which has a big disadvantage due to inherent complications related to communication and data transfer between the individual workstations and the file server. They are also difficult to manage because of the degree of independence between the workstations, problems with different OS versions, security concerns, etc. Consequently, we do not recommend P2P architecture for systems larger than about 20 workstations.

The best performance will be a Linux (CentOS or RHEL) system with local (not NAS or SAN) dedicated disks: local to avoid the latency of communication across some kind of network connection, and dedicated to avoid file locking delays inherent when a disk subsystem is shared between multiple computers. Virtualization is not a significant factor, but a multi-core "server class" (e.g. Xeon) CPU is. In the Linux environment, workstations should be connected over SSH2 connections, preferably from ATE (A-Shell) clients. 16GB RAM should be more than adequate for 250 users.

For sites that want to stick with a purely Windows solution, the next best thing would be a Windows server where all of the processes run directly on that server. Because of the higher overhead of Windows processes, this requires a more powerful server, with a lot more memory than for the Linux case, but if you can build a server capable of hosting simultaneous Terminal Service sessions for all your users, then that will be an acceptable solution. It doesn't have to be Terminal Services/RDP; it could also be TELNET/ATE, or Citrix, or one of the other similar protocols which effectively turn the workstations into mere terminals rather than independent computers merely sharing the server's disk resources. Any of these designs will have a higher price-to-performance ratio compared to the Linux solution, but with enough resources should give adequate performance. Since this design only makes sense in the presence of significant local technical knowledge, you should defer to them to determine adequate RAM and CPU resources.