Typical 1000-user in-house installation

(This document/configuration now obsoleted in favour of multiple transferable virtual servers, but retained for reference.)

Rather than individually answer critics who challenge our system concepts, we offer the following in-house system suitable for a college/hospital/local-government-authority, based on £50,000/$90,000/€75,000 per annum.

All PCs are 3GHz 4GB twin SATA Raid, all links Gigabit except 100mbps Linux/Apache web server links to Internet/LAN.

Average PC cost including Gigabit PCI adapter and OS etc. less than £1500/$2100/€2000, Buffalo Terastations £600/$1000/€900 each, USRobotics 16Port Switch £130/$210/€195 (if Linux/Apache web servers are linked with application PCs by 100mbps Ethernet rather than thru Gig switch – all the PCs came with 100mbps Ethernet as standard with motherboard).

Total cost of system – less than £25,000/$45,000/€40,000 or £25/$45/€40 per concurrent user. Plus, of course, annual maintenance charge and CATERMAN charge of £100/$200/€150 per power user per annum (apologies for previous pricing error!).

Performance is based on CATERMAN average user requiring web page every five seconds (in practice some screens take much longer for the user to complete, and the simple screens require small simple returns anyway), the average screen containing 2K html constructed by CATERMAN plus however many K Gifs etc. required supplied by the above web servers/other internet or local web servers/user PC.

Thus, the CATERMAN data load from the application servers to the web servers and hence to the internet is as low as 0.4K bytes per user per second, i.e. 400KBPS or 3.2mbps, generally accommodated by two 10mbps internet connections (one for each web server) where some graphics are provided from the web servers.

All software and journal logs are recorded on the originating web server/application PC.

Additional web servers may be added if performance enhancement is required, but system relies on users being allocated to a specific web server with fall back to alternatives if the server is out of action for any reason.

Each application server supports up to 100 concurrent users, with the option of increasing user numbers per PC as PC power increases or twin processor systems are incorporated, or decreasing user numbers per PC and adding extra application servers if loading is excessive depending on user type mix.

Each table of the database is allocated to an appropriate data-server depending on user-mix, and monitored, with the option of adding further data servers as required for performance (the data capacity is far greater than needed for 1000-user CATERMAN anyway). Each data server can deliver up to one Gigabit of data per second (125MBPS) via the Gigabit Ethernet connection to the requesting application server PC which is almost the performance of directly-attached 150MBPS SATA (first generation), and of course each application PC is simultaneously receiving/writing data both to its own internal SATA storage and the web servers.

This configuration provides for failure of any single disk drive at any one time, with hot-swap facility. It does not provide for 100% total resilience against multiple simultaneous failures in the same device. A double disk failure in a NAS device will necessitate partial database rebuild from journals, for example, and some downtime.

A considerable improvement in performance and resilience is expected by substituting IBM DS4000 NAS devices with 16GB memory and double fibre-optic Ethernet links together with a fibre-optic switch link to application PCs and the second link used to connect together the DS4000s to support hot back-up via mirrored data write across NAS devices preferably sited in different locations with fibre-optic link. In effect, the entire system split between two locations with one web server, five application servers and two DS4000s in each rack, with double fibre-optic links supporting two separate Ethernets, one for linking the application servers to the DS4000s and one linking the DS4000s to each other. Each location can then be switched to work independently should the other location be out of action, with minimal downtime.