An A-Shell developer is working on a big new project and has asked my advice about the fastest kind of computer to run an A-Shell application. This will most likely be an application with lots of users, and very LARGE files. I don't have enough experience with different hardware environments to be able to give a definitive answer (and doubt that anyone could, in fact, do that). But in any case, all suggestions or observations about performance-maximization would be most appreciated, including, but not limited, to the following topics:
1. Brand names (IBM, Dell, HP, etc.) and models.
2. OS (most likely Linux) and distribution.
3. CPU type: Intel vs AMD. Multi core, multi CPU?
4. Disk technology and configuration.
For my part, a mixture of incidental and anecdotal experiences, and some theoretical knowledge have led me to the following prejudices:
A. Linux is far faster than Windows. (I'm less sure about how Linux compares with AIX, although our largest systems in the field - over 500 users - do happen to all be AIX.)
B. Dual CPUs are better than a single dual-core CPU. This is logical because A-Shell is single-threaded. Two A-Shell instances can each run on one of the separate CPUs, but I don't think they can share the cores of a single CPU. Dual core may have other benefits though - certainly for OS kernel code, and nowadays are practically standard. 64 bit CPUs do not offer any significant advantage for A-Shell.
C. SCSI or SAS is faster than SATA, particularly when their are queued requests, although perhaps this difference is minimized in very high-end RAID environments. SCSI is also more expensive, but the drives seem to have fewer failures. 15K RPM drives are significantly faster than 10K, since that reduces the average latency (involved in every random access) from 6ms to 4ms. With average seek times in the range of 7ms, those extra 2ms are significant.
D. A-Shell apps are almost always disk-bound before they are CPU-bound. Thus, money should be directed towards the fastest disks, rather than just the highest CPU MHz (which, as you'll notice, is how inexpensive systems are always advertised).
E. In most cases, simple mirroring (RAID 1) is faster than striping (RAID 0, 5, etc), because a smart controller can seek independently from either physical disk. Having multiple independent disks (or mirrors) is better than a single disk subsystem, for the same reason. Put the OS on one disk (or mirror unit), the app on another, or perhaps split the most commonly accessed files in the app on to different physical disks.
F. Application configuration and design may make as much of a difference as hardware, and is difficult to give general advice about. But here are a couple of pointers anyway:
- Don't put too many files in one directory. After several hundred, performance really starts to suffer. Use more directories instead. I see this all the time, where people create sequentially-named output files by the thousands and just put them all in one big directory with the rest of the application files. And then wonder why performance tanks.
- For large files, ISAM is much better than binary search schemes like SERCH.SBR. (A 64K record lookup will take 16 disk accesses in SERCH.SBR, and probably only 4 in ISAM.) An exception might be if you can memory-map the index file, since memory-mapped i/o is so much faster than ordinary i/o.
