If these companies were to see a measurable percentage of their revenue coming from the Web, we would likely see an increased demand for features such as geographically dispersed mirrored sites and increased redundancy in the host LAN. It will probably take an explosion in electronic commerce or a disaster of major proportions at a Web-hosting facility b efore most companies are willing to pay for these services. We also may see redundancy creep in as a value-add to the basic offering as competition heats up among providers.

We spent a considerable amount of time evaluating Web-hosting services, and one point rang out loud and clear in the area of redundancy--much of the nuts and bolts of Web hosting is a black box. Many providers we spoke with were unwilling to disclose information pertaining to the redundancy in their LANs. Complicating matters even more, it seems that redundancy means different things to different people. The bottom line is if fault tolerance and redundancy are important to you, be sure to open the black box.

Redundancy is very important to The Walt Disney Co., which chose AT&T to host its site. Disney's T3 lines from two carriers have automatic failover and run into network access points (NAP) in Washington. Each server has two LAN interfaces and each LAN interface connects to a separate 100-Mbps Copper Data Distributed Interfa ce (CDDI) ring. The routers and firewalls also are redundant, and servers are mirrored with automatic failover--this site is designed to stay up.

IBM has experience hosting large sites with a l ot of redundancy. It has developed Network Dispatcher (www.ics.raleigh. ibm.com/ics/issbeta.htm) for load-balancing and optimizing global traffic across remote mirrored servers. Some sites that IBM has hosted with this technology are the Olympics, Wimbleton, the U.S. Open and the Deep Blue Chess Challenge. Network Dispatcher is available on AIX and should be available on Windows NT and Solaris late in the first quarter of 1997.

Caveat Webtor Since the biggest "gotcha" with Web hosting is slow server response, here's a primer to give you better footing when shopping for a service provider.

If not caused by network problems, slow server response is often due to delays caused by swapping to disk. Swapping to disk occurs when too many hits are coming in for the amount of available RAM. With the low p rice of RAM these days, servers should be sized appropriately for estimated peak loads. As a rule of thumb, you'll need 1 MB of RAM for each concurrent user on Unix or NT. CPU cycles and disk I/O are two other resources that also should be monitored.

Other reasons for going to disk, such as authentication of visitors by checking against a database or generating Web pages on the fly, slow server response considerably. Ensure that your provider caches your most popular pages in RAM.

Another gotcha to look out for is Perl; it's well-suited for text, but doesn't perform well on the Web. On heavily loaded servers, the Perl Common Gateway Interface (CGI) scripts run two times slower than CGI scripts written in C.

Additionally, each CGI script creates a new process in Unix or a thread in NT. The process table has to be locked, memory has to be allocated, environment variables have to be passed, and so on. This creates a limit of about 20 CGIs per second. Using NSAPI, Netscape's server plug-in, you can ru n hundreds per second. (Microsoft has a similar technology called ISAPI.)

Another bottleneck to avoid is server-side includes (SSIs). SSIs have to parse the entire document every time they run. Performa nce, measured in connections per second, drops by a factor of 10 when using SSI.

An often overlooked performance variable is OS tuning. Unix and NT weren't designed to optimize HTTP. OS vendors often have patches available that are aimed at improving the response of Web servers. For raw server performance comparisons, point your browser at the SPECweb benchmarks (www.specbench.org/results.html).

Most modern Web servers offer administrative tools that can assist you with server response. A number of Unix utilities such as iostat, swapon, vmstat and sar also can give you these answers. When pressed for answers, a hosting provider may be vague. We suspect that some providers are swapping server hits to disk when things get busy to keep costs down. These providers know what's going on with your server, so insist on getting real answers when performance and reporting are concerned.