We have been asked for recommendations on buying a ten-user Windows system, and have researched the matter a bit. Following are points that one would want to take into consideration if purchasing such a system for use with A-Shell. Keep in mind that:
- This discussion does not consider what resources other applications—besides A-Shell—may need to run on the network. Since conventional PC applications, such as Microsoft Office, may very likely have more of a performance impact on a system than A-Shell, those applications should be fully and separately evaluated.
- Serial ports and modems are not included in the discussion, as they generally are not relevant in modern network environments. If you need either of these components for legacy applications, consult with the vendor before purchasing a system.
- We are not recommending Dell, but because it is a kind of standard, it seems reasonable to use as a benchmark for prices and configuration.
- This material was written in December 2015.
That said, here are the major points to consider:
- Server-class hardware: A-Shell does not require “server-class” hardware, and will run fine on a desktop machine. However, for a ten-user system, it seems reasonable to select server-class hardware for reasons of reliability, service and performance.
- Operating system: A-Shell does not require Windows Server; it can run fine on a “Pro” version of Windows, even if using the ATSD/Telnet option. However, many system providers insist that if you choose server-class hardware, you install a server-class OS. Plus most customers, service techs and IT professionals would probably expect a server OS for a ten-user system. Windows Server is better at time-sharing, i.e. better at supporting multiple active users, and offers better management capabilities than the workstation versions. (These advantages, however, will be canceled out if you load the server up with all kinds of other server responsibilities unrelated to A-Shell, e.g. SQL Server, Exchange, etc..) But Windows Server is more complicated than the workstation versions, so if you are the one installing/configuring/maintaining it, expect to spend some time learning it. Note that for Windows Server, you’ll need Client Access Licenses (CALs), which cost about $30 each in 5 packs. You don’t need those if just using a workstation-class version of Windows on the “server”.
- Virtualization: Highly recommended for ease of deployment, flexibility in backup and recovery, migration, managing growth, etc. But it adds several hundred dollars to the cost of a Windows server, and there is a learning curve, so it might not be advisable if you have only one server to maintain or don’t expect to use the flexibility virtualization affords.
- Telnet vs Peer-to-Peer: File I/O performance will be much better using Telnet to connect the workstations to the server, vs. peer-to-peer file sharing. (Simple tests of running reports suggest that a 5X differential is common.) The main advantages of P2P are cost, simplicity, display performance, and ease of integrating workstation capabilities with the application on the server. These have to be balanced against the much slower file I/O, lack of remote connection capability, and dependence on a reliable LAN. The cost differential is due to the requirement for the ATSD server component and telnet clients (preferably ATE), neither of which is required in the P2P model. For applications that are heavily dependent on GUI and/or integration with Windows client extensions, Terminal Services (Remote Desktop Protocol or RDP) may be preferable (and slightly more expensive) than ATSD/Telnet.
- CPU: A-Shell is not very CPU intensive compared to most other Windows applications, so it is not necessary to spend a lot of money for the fastest processor. However, all Windows servers —and even workstations—can benefit enormously from a multi-core CPU. And in the Telnet or RDP case, since all the users will be sharing the server CPU for the application work, a server-class CPU (e.g. Xeon) may well be justified.
- Memory: Most A-Shell applications are not very memory intensive either, compared to typical Windows applications. You can probably assume that 50MB of server memory per user is sufficient, which means that a ten-user system needs only about 500MB for the users’ application memory, plus whatever else you may want for the server itself. 8GB, which is now rather typical even for workstations, will be more than fine. The exception would be if your application likes to load massive amounts of data into memory for the purpose of sorting, or for manipulating databases directly in memory, such as with auto-extending or associative arrays, in which case, just use common sense.
- Disk: Capacity is typically not a concern, since most A-Shell applications’ data storage requirements are modest compared to typical Windows applications or Windows itself. But performance may well be a concern, as A-Shell applications are often quite disk-intensive due to the record-oriented transactional data-processing paradigm typically followed. So while a standard SATA drive might be adequate, investments in faster disk subsystems (7200+ RPM, SAS vs SATA, RAID, SSD, etc.) may noticeably improve the performance of disk-intensive applications with many users competing simultaneously for access. Let your budget, knowledge of your application, performance expectations, tolerance for waiting, etc. guide you.
- Network: A-Shell has no special network requirements, but since networking is fairly critical in any modern system, it is worth spending a little extra for a dual port Gigabit network controller on the server, and configure your LAN (switches, subnetting, policies, etc.) so that it is relatively free of extraneous traffic (like video and music streams, online backup, cross-LAN-antivirus, etc.) and can be maintained that way. A few hundred extra dollars for a switch that can tell you there is something wrong with one of the lines or interfaces and can otherwise help you monitor the health of the network may be well worth the investment.) Note that Windows Server 2012 makes it easy to “team” the dual-port network interfaces, whereas this can be tricky and require third party utilities to accomplish on a workstation version of Windows.
- Backup: We don’t have any particular advice here, other than to make sure that you do it regularly!
- Maintenance Plan: Yes!
- Cost: Obviously, the cost of a system ranges widely, but as the attached Dell quote shows, you can get a pretty good server for under $3000, including a 6 core Xeon CPU, 500 GB 7200 RPM RAID 1 disk subsystem, 8 GB RAM, and 3 yr NBD service—but not including a backup device, installation, or any special remote/consultation services. You could probably put together a more basic server (non-server OS, no RAID, i7 CPU) for less than half that. Or, for about twice this price, you can get a deluxe high performance server, with 15K SAS drives, RAID10, virtualization, RDP, installation, consultation support, etc. Here is the same Dell quote showing all options.
- Server in the Cloud: As an alternative to dealing with all these hardware issues, you may want to just rent or lease a server in the cloud, such as Amazon’s EC2 service, which vastly simplifies most of the aspects of putting together a server, eliminates the need for up-front purchasing or financing, and gives you maximum flexibility for changing your requirements at any time. Costs for a system like the one described here might be in the vicinity of $35 – $75/month.