Server Performance

Whilst this chapter should give you enough information to know what the main issues are with setting up and running a WWW server, it is still possible to end up with a server that doesn't perform too well. If your server is lightly loaded, then this is probably not a problem, so ignore this section. However, if you provide interesting information, your server may be inundated with requests, and you may need to consider it's performance. If you're used to systems administration, then the following tips may be obvious, but many servers are run by people with little systems administration experience, and as this group of people is increasing rapidly, we've added a few pointers:

How does your server start?

WWW servers running on Unix (or similar) systems have two ways to start - either from inetd (the Internet Daemon) when a connection arrives or at system boot time and the application listens continuously for incoming connections. Starting from inetd is much slower than starting a single copy at system boot time.

Where are the files you're serving actually stored?

Although you may consider you LAN to be fast and your WAN to be slow, if your server has to get your files from a fileserver on a different machine, this will load your LAN unnecessarily, and slow down your server's response time. On some systems, it may be possible to use a caching filesystem to do this if you can't put all the files on the WWW server machine.

How does your server resolve it's UID and GID?

Both the CERN and NCSA servers let you start the server as root (so it can use port 80), and then set the user ID and group ID to a none privileged account. This is a very good idea from a security point of view. However, if your server used NIS (Network Information System) to obtain the user and group IDs (particularly the supplementary groups), it will have to pull your user and group database files across your LAN from the NIS server for every WWW access. It may be a good idea to run a slave NIS server on the same machine as the WWW server to improve this performance.

Does your server have enough memory?

It's pretty obvious, but if a machine is thrashing (the active processes use more memory than is available, so you're paging from disc continuously), then it will perform badly.

On systems such as the Macintosh, there's only one running server, but the memory it uses increases as the number of simultaneous connections increases. Check the server at busy times to ensure its memory allocation is sufficient.

How efficient are your CGI scripts?

If your server is seeing a lot of accesses to CGI scripts, those scripts may dominate the performance of your server. Scripts that do a lot of database searching, or use a lot of files from another fileserver may cause you problems. If this appears to be a problem, consider running another WWW server on the database machine itself, moving the files to the WWW server, or using a caching filesystem to improve the situation.

How stable are your CGI scripts?

It's not uncommon for badly written CGI scripts to contain bugs that cause them to loop indefinitely. Whilst you would probably notice this immediately with a normal program, a WWW user not getting a response from a server is quite likely to try again, and hit the same bug again!

Some servers can be configured to kill CGI scripts after a certain amount of time. Check how long you thing your scripts should take to run, and set this value accordingly. However, if you do this, you may never discover malfunctioning scripts unless you set them up write a log entry when they're started and remove the log when they finish correctly.

Have you turned off RFC1633 authentication?

Some servers (such as CERN HTTPD) permit you to enable RFC1633 authentication, which attempts to query the client machine about the username of the person making the request. This information is unreliable at best, and if your server is busy, it is best to disable this feature.

Who are your users?

You can analyse who your users are (or rather where they come from). If many of your users come from one area that is not local to you, consider setting up copies of your data elsewhere.

Have you considered setting up a caching server?

If your server is busy with requests from elsewhere, your local users will get poor performance to the rest of the world. Consider setting up a caching server (such as CERN HTTPD), and configuring your local user's clients to use it. This will help them, and will also reduce the load your own users cause elsewhere. If you can't set up your own caching server (because there's not one available for your hardware), then consider using someone else's. Enquire whether your network provider is running a caching server, and if they're not then encourage them to do so.