In addition to ifconfig, netstat is another standard Unix tool and useful for monitoring a network under Unix. It can extract a lot of different kinds of information on all or just one network interface. A short rundown of some of the arguments netstat uses will give you an idea of how to use this tool (see Table 1-6).

Argument	Effect
	Display open connections (sockets)
-a	Also show listening and non-listening sockets
-c	Redisplay selected table continuously
-i	Display network interfaces
-n	Display IP addresses, don’t resolve names
-r	Display network routes
-s	Display network statistics
-v	Provide verbose information

Table 1-6. Command Line Arguments for netstat

netstat supports many more arguments, especially for the default (open network connections) table—see http://snowhite.cis.uoguelph.ca/course_info/27420/netstat.html for details.

Examining the Packets

Both these utilities enable an administrator to examine the packets being sent on a network. snoop is available on Solaris, and tcpdump is a free tool of similar capability available on Linux and FreeBSD. (It can be used on any platform that can build it because the source code is freely available.)

Both tools allow packets to be examined as they appear on the network. Various options allow packets to be filtered according to source IP address and port, destination IP address and port, protocol, message type, and so on. For example, Apache’s communications could be monitored on port 80, filtered down to data packets.

Note that it isn’t necessary to be on the server to do this. Any computer connected to the same network as the server will do, but Unix usually requires that a user is privileged to spy on the network for security reasons.

Pinging the Server

ping, the simplest and handiest network tool of them all, sends out an ICMP message to a remote hostname or IP address to establish that it’s both present and reachable and reports the time taken for the round-trip. Most versions of ping also allow the remote server to be pinged at regular intervals—handy for preventing a network connection from timing out and disconnecting.

Testing the Handling Capacity of the Network and Server

A variant of ping whose name may vary, spray floods a destination server with ping packets to test the handling capacity of the network and server. The higher the percentage of packets that reaches the destination, the better the network. This is an unfriendly thing to do to a network that’s handling real network traffic, so you should use it with caution.

Diagnosing Problems

traceroute is useful for diagnosing problems with establishing network connections, for example, in cases where ping fails to reach the remote server. traceroute uses the ICMP protocol to ask for routing information from every intermediate step in the route, from the host to the destination. Across the Internet, this can return upward of 20 lines in some cases.

traceroute is particularly useful when diagnosing problems surrounding failed connections because it can sometimes pinpoint where along the line the connection attempt is failing. It can also be useful for determining incorrectly configured or faulty systems in the network. Again, see http://www.stopspam.org/usenet/mmf/man/
traceroute.html for more information.

When choosing server hardware for your Web site, there are several issues to consider, especially whether to buy hardware at all. See the section “Get Someone Else To Do It” at the end of this chapter for more information.

Apache runs on a wide range of platforms. Typically, it runs on Unix systems, of which the most popular are the free Unix-like operating systems, Linux and FreeBSD. MacOS X is also popular, if only because every machine shipped with OS X includes an Apache installation by default.

Apache also runs on Windows NT, but Apache 1.3 isn’t quite as smooth on NT as it is in the Unix implementation. Apache 2 is better suited to Windows and provides improved performance and resiliency. There are also efforts to port Apache to other platforms in case you have a specific preference for one as yet unsupported.

Corporations that have service contracts and care about support should opt for the most relevant platform, assuming it runs Apache and performance and stability issues aren’t a concern. For anyone on a budget, a cheap PC with Linux or FreeBSD is economical, and both platforms have a good record for stability. Building an inexpensive cluster out of a selection of cheap servers is also more practical than it might appear at first. Simple clustering can be done using nothing more than Apache and a name server. For a simple server with undemanding Web sites, even an old 486 can be perfectly adequate. If you have old hardware to spare and want to put off a purchasing decision until you have a better idea of what you’ll need, older machines that have been retired from desktop use can fit the bill nicely. Alternatively, you can buy a cheap PC for development in the interim.

When it comes to free software, Linux and FreeBSD are both popular choices. The main difference between them is that FreeBSD is slightly more stable and has faster networking support, but Linux has vastly more software available for it. The distinction is slight, however, because Linux is easily stable enough for most Web applications, and porting software from Linux to FreeBSD is usually not difficult.

If stability is of paramount importance, and you don’t intend to install much additional software, choose FreeBSD. If you plan to install additional packages for database support, security, or e-commerce, Linux is probably preferable. Other BSD variants that are popular for Web servers are OpenBSD, NetBSD, and of course MacOS X.

As of writing, the following platforms fully support Apache:

Basic Server Requirements

If you’re in a homogeneous environment such as a company, it makes sense to use the same kind of equipment for your server as you use elsewhere, if only to preserve the sanity of the system administrators and make network administration simpler.

However, this isn’t as important a consideration as it might seem. If your server isn’t strongly connected to the rest of the company intranet (for example, if it doesn’t require access to a database), it’s a good idea to isolate the server from your intranet entirely for security. Because there’s no communication between the Web server and other servers, compatibility issues don’t arise.

Apache will run on almost anything, so unless you have a specific reason to buy particular vendor hardware, any reliable low-cost or medium-cost PC will do the job. Stability is far more important than brand.

Using Dedicated Hardware

One point that is still worth mentioning: Run Apache on its own dedicated hardware. Given the demands that a Web server can impose on a server’s Central Processing Unit (CPU), disk, and network, and given that Apache will run on very cheap hardware, there’s no reason not to buy a dedicated server for Web sites and avoid sharing resources with other applications. It’s also not a good idea to use a computer that hosts important applications and files for a public-access Web site.

Using High-Performance/High-Reliability Servers

For demanding applications, consider using a multiprocessor system. With expandable systems, you can scale up the server with additional processors or memory as demand on it increases.

Alternatively, and possibly preferably, from both an expense and reliability point of view, clustering several independent machines together as a single virtual server is also a possibility. Several solutions exist to do this, as well as use custom clusters, which I cover in Chapter 7.

You can never have too much memory. The more you have, the more data can be cached for quick access. This applies not only to Apache but to any other processes you run on the server.

You need the amount of memory that allows the server and any attendant processes to run without resorting to virtual memory. If the operating system runs out of memory, it’ll have to temporarily move data out of memory to disk (also known as swapping). When that data is needed again, it has to be swapped in and something else swapped out, unless memory has been freed in the meantime.

Clearly this is inefficient; it holds up the process that needs the data and ties up the disk and processor. If the data being swapped is the Web server’s cache or frequently accessed database tables, the performance impact can be significant.

To calculate how much memory you need, add the amount of memory each application needs and use the total. This is at best an inexact science, so the rule of thumb remains: Add more memory. Ultimately, only analyzing the server in operation will tell if you have enough memory.

The vmstat tool on most Unix systems is one way to monitor how much the server is overrunning its memory and how much time it’s spending on swapping. Similar tools are available for other platforms. Windows NT has a very good tool called perfmon (Performance Monitor).

An operating system that handles memory efficiently is also important (see the “Operating System Checklist” section later in this chapter).

This article is excerpted from Pro Apache by Peter Wainwright (Apress, 2004; ISBN  1590593006). Check it out at your favorite bookstore today. Buy this book now.