In May 2007, an A-Shell developer started a big new project and asked our advice about the fastest kind of computer on which to run an A-Shell application. The application will have lots of users and very large files. We here at MicroSabio don't have enough experience with different hardware environments to be able to give an absolutely definitive answer—and in fact, doubt that anyone could do so. But a mixture of incidental and anecdotal experiences, along with some theoretical knowledge, have led to the following prejudices:

Platform

Linux is far faster than Windows. It's less clear how Linux compares with AIX, although our largest systems in the field—over 500 users—do happen to all be AIX.

From FDM in Florida, May2007: We are a dedicated Linux shop, and it is extremely fast and robust. It bogs down when using the main console, though, so don't throw any activity there.

CPU

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.

Memory

From FDM in Florida, May2007: I would definitely splurge on extra RAM, and go with at least 2GB. Linux caches very well, and often repeat disk requests don't even hit the hard drive. (A-Shell also caches well, if you have all the tweaks setup in miame.ini.)

Disk Drives

SCSI or SAS is faster than SATA, particularly when there 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.

From TJ in Sacramento, May2007: 15K drives run much hotter than 10K drives, therefore the enclosure must have positive disk drive ventilation.

Disk Dollars

A-Shell applications 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.

RAID

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.

From TJ in Sacramento, May2007: I've recently started using RAID 10 for my high performance installs. This is a mirror of striped drives. I was very surprised when I first benchmarked this configuration. This was MUCH faster than a RAID 5 and 10% faster than a RAID 1 for writes and almost 20% faster for reads. This does require 4 drives to net 2 but it really made a big difference.

Configuration and Design

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. This is a common problem, 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.

More Information

Given the pace of change in the computer hardware environment, the information presented above may be accurate or hopelessly out of date. For more information and the latest discussions on this subject, see the relevant discussions on the A-Shell forum.