Proposed Web Server John Mann Network Services Group Monash University Computer Centre Introduction ------------ The increased reliance by the University on Word Wide Web services has led to increasing demands of the central Web Server. This server provides the official Monash University Web home. It also provides Proxy Web services for people (especially students) to access the Web outside Monash and to save network usage costs and reduce delays. Web usage is growing at a phenomenal rate. Some estimates have Web traffic doubling every 5 to 6 weeks. Our Web server is already overloaded. A lot has already been done to reduce the load on this server, but it has just not coped with demand since the start of second semester. The Web server's CPU is overloaded, the Proxy cache is too small, and it can not support a high enough I/O request rate. It is essential to upgrade the Web server to a faster machine with more CPU power, disk space and I/O request rate in order to provide decent support for the Monash Home Page, provide better Web services for students and save network bandwidth (and charges) through a larger proxy cache. It is also essential to upgrade to a machine that will support not only the current load, but the expected increase in load over several months. Also this machine will need to be expandable in various ways to handle unexpected future changes in demand type. Summary ------- DA-253P1-J9 AlphaServer 2100 5/250 128MB 2GB $91,420 MS450-CA 128MB $13,800 KZPSC-BA 3port RAID controller $3,288 13 disks RZ29B-VW 4.29 GB 7200 rpm Wide @ $2,515 $32,695 VT320 console $285 DE500-XA Fast Ethernet $255 BA35E-SA Internal wide storage shelf $602 H7893-AA 2nd 2100 power supply $1,806 TZ87-TA Tabletop DLT 20GB tape drive. $6,300 QB-4G4AA-WB NetScape Proxy Server $3,318 QB-4G4AA-GZ Doc Kit $150 -------- Total cost of recommended solution is $153,919 -------- z=91420+13800+3288+32695+285+255+602+1806+6300+3318+150 -------- This system uses the fastest uniprocessor 2100 currently available and will provide high performance for multi-threaded server processes. This system is expandable in that it allows for 3 more CPUs to be added and for more memory to be added. It also can take up to 6 3-port RAID controllers for a maximum of 126 disks, or can be clustered. Commercial Proxy Server software is recommended in order to provide a high quality solution. A 20GB DLT tape drive is recommended in order to backup the large amount of disk on this system in a reasonable length of time. To obtain decent throughput from this system will also require the (subnet 1) network infrastructure to be upgraded to provide a 100 Mbit/s path to the core Monash network (and switched 10 Mbit/s for hosts). Approximate cost $40,000. Performance Comparison --------------------- The current CERN http and caching proxy server performs ~4 requests per second. Each request uses ~4 SPECmark89 CPU seconds and ~10 disk I/Os per request. We can have up to 90 http requests active concurrently. The current request type ratios are local http 19% average request size is ~6KB from cache 29% average request size is ~10 KB proxy from elsewhere 50% " The current CPU can support ~4 requests per second. The old singe Web disk could support ~5 requests per second but this has now been split over 2 disks and is not a bottleneck any more. An AlphaServer 2100 5/250 running the existing code should support ~60 requests per second. The latest 7200 rpm disks should support ~8 requests per second each, hence 8 disks recommended for the cache. The memory should allow for ~600 concurrent requests. The proposed machine should be ~16 times faster than the old one, and so it is guessed could handle 20-24 weeks of exponential growth as seen at the University of Melbourne. Allowing for the semester breaks the new system should handle the Web growth until the end of 1st Semester 1996. Other Factors ------------- The pre-forking Netscape Communications Server software is expected to use less (say half) the CPU that the CERN http server does. Similarly, The pre-forking Netscape Proxy Server software is expected to use less (say half) the CPU that the CERN proxy server does. A different option is to use the multi-threaded Harvest Cache proxy server is expected to do less (say half) the disk I/Os, but doesn't keep the cache across reboots. I think the CPU saving from using a pre-forking or multi-threaded Server should enable the Web server to keep up with demand for another 6 weeks or provide other sorely-needed services. that the current brother does not, due to lack of CPU power. These services include Forms and CGI support, Hypermail, user-requested statistics gathering, a Web server index, DReSS (Document Repository Server) ... Disks ----- Apart from the cache disks, I think another 4 disk spindles are required to spread the anticipated load, plus one more for RAID support. programs, gopher and wais files (1 disk) http files (2 disk set) logs (1 disk) Parity (1 disk) The jury is still out on what is the best way to provide a large, fast, reliable and expandable cache disk. There are 3 options: 1) RAID 5 can provide a reliable virtual disk. However, increasing the size of this virtual disk requires a complete backup, reconfigure and restore of the whole disk set -- which could take a day or two for a large cache size. I think writing to a RAID 5 set will be slower than writing to other types of disk storage because the Parity Disk (and perhaps the old data) need to be read, the parity data XORed with the old data and the new data and then the data and parity disks need to be written. 2) ADVFS can provide an easily expandable virtual disk, but has been known in the past to give problems if the underlying physical disks aren't reliable, or if the average file size is small. A possible solution to the disk reliability problem would be to take 4 x RAID 1 (Shadow) 2-disk sets and then bind these into an ADVFS set. There might be some tuning commands that get around the small file problem, or Digital UNIX V3.2C might have fixed some of the bugs. 3) RAID 0. This gives the fastest performance, but low reliability. The WWW Cache *could* just be cleared and refetched by the users if the disks become corrupted or when their RAID configuration needs to be changed. However a 32 GB cache that Monash was charged $0.50 per MB to fetch would be worth ~$16,000. We wouldn't want to throw that away too often! I propose that we buy enough disks so that we can use any option above. The cache should initially be configured to use only some of these disks in a RAID 0 set and the other disks used to experiment with the other options.