Installing Apache Tutorial

• Download Apache
• Compiling the Source
• Using Apache

• Know your Directives
• Server Side Includes
• Make those CGI’s Work
• Error Documents
• Content Negotiation
• A Single Config File
• Rotating Logs
• Get some Extras
• Buy a Book

• File Lookups
• Hostname Lookups
• Content Negotiation
• Hardware
• Server Processes

Let us get started then, shall we?

Introduction

Most people associate quality and popularity with price. On the Web though, this is not the case. What is the most popular, highest quality Web server available?

• The Netscape-Enterprise server? Wrong.
• Microsoft-IIS? Wrong again
• Apache? Bingo, and by a staggering amount.

The Apache Project (http://www.apache.org/) started back in 1995 when a group of Webmasters decided they needed a stable, powerful server for an upcoming site (one of these sites was http://www.hotwired.com/). At the time, the most popular server software available on the Web was developed by the National Center for Supercomputing Applications (NCSA). The developer, Rob McCool, left the organization and all development was stalled. At the time, Webmasters were making their own extensions and bug-fixes for the server, but these were not distributed in any way. The group of Webmasters decided to co-ordinate the changes to the server, which later became known as ‘patches’. This is how the Apache Server got its name: A-Patchy Server. A year after the release of the Apache Server, the small group of hackers had created the #1 server on the Internet.

Being able to view the source code for the server is one of its biggest advantages. Not only can you modify and add features to the server yourself (providing you know C++, or Perl if using mod_perl), but the vast number of developers out there have made modules to add on to the server.

Due to it’s popularity, we decided to create a group of tips and tutorials to help you install, configure/customize and optimize your Apache server. Since Apache is available for Unix and Windows, we will specify whether a tip is platform-specific.

Starting Off

Installing Apache and starting it up is generally thought to be a gruelling task, which it shouldn’t be. In fact, with these tips and tutorials, it should be quite easy for anyone. The installation of the Unix version of Apache is just like installing most other applications, you download the source, compile it, and voila! The Windows version also makes it easy; using the setup wizard, it’s just like installing any other Windows application.

Anyway, first we need to download a copy of Apache. Since it is relatively small (the size ranges from 1 to 3MB, depending on the platform), this should be a painless procedure. After that, it’s just a matter of installing it. The following tips will make this procedure as painless as possible.

Download Apache

To get Apache, obviously you have to go to their site at http://www.apache.org/. Proceed to the downloads (http://www.apache.org/dist/) section or find the closest Apache mirror to you (http://www.apache.org/dyn/closer.cgi) to get your copy.

If you would like the Unix version of Apache, go through the well-named list of files and grab the gzipped copy (apache_1.3.9.tar.gz). For the Windows version, download the Windows binary setup file (apache_1_3_9_win32.exe).

Since installing the Windows version is easiest, I will talk about that first. After the file is downloaded, just open it as usual and the setup wizard will open and install the server for you. Since Apache has just started making Windows versions, the code is not as stable as it is for Unix. Windows support is entirely experimental, and is recommended only for experienced users. The Apache Group does not guarantee that this software will work as documented, or even at all. During the installation, you will be asked for

• the directory to install Apache into
• the start menu name
• the installation type

Now to the Unix version. Since you downloaded a “tarball” distribution, you have to decompress it. Simply type tar -zxf apache_1.3.9.tar.gz. A directory called apache_1.3.9 will be created. You will have to go to this directory to proceed to the next step and compile the source code.

Compiling the Source

With all the source code neatly placed in this directory (and it’s sub-directories), you will have to compile it to make it work. Here we will be using the GNU cc (gcc is the shortform) compiler to compile the source. It is free and distributed with most Unix operating systems. If it is not on your computer, download and install it from http://www.fsf.org/software/gcc/gcc.html.

Anyway, once in the apache_1.3.9 directory, from the prompt type

./configure

This will create a makefile with the default configuration. To change the configuration, you must edit apache_1.3.9/src/Configuration.tmpl before running configure. You can add/remove modules from the list, and tweak many other options. Normally though, you should just let it use the defaults, especially if this is your first time installing Apache.

For more information on editing the Configuration file, check out the README.configure file included with the distribution.

Two more command line commands to execute. Type

make

to compile the server, and

make install

to put it in the proper directories. The default is /usr/local/apache/, though this can be changed in Configuration.tmpl. Now that your Apache binaries have finally been installed, we can proceed with learning how to use them.

Using Apache

After all of this work, we are now ready to start running Apache. There are obviously two methods for running it, one is for Windows and the other is for Unix.

Windows

Since Apache is just another Windows application, just go to the start menu, then the Apache Web Server program group. If you are not running Windows NT, just select “Start Apache as console app”. If you are running Apache on NT though, you can hit the “Install Apache as Service (NT only)” option and Apache will be installed as a service on your computer. This means it will automatically start everytime NT is booted up.

To shutdown the server, there are two other options available in the start menu that should be self-explanatory.

Unix

To startup Apache in Unix, all you have to do is run httpd. This would look something like this

/usr/local/apache/httpd

but this also depends on where you installed the binary. It will automatically use the configuration file it created on compilation called httpd.conf. If you would like to use another configuration file, you can use the -f argument.

Ex. /usr/local/apache/httpd -f /usr/local/apache/conf/httpd.conf

The Apache distribution does come with another method of starting, stopping, and restarting Apache. The script is called apachectl. In the Apache src directory (apache_1.3.9/src), type make at the prompt. You will see a few more files compiled. After make is done, go to the support directory (apache_1.3.9/src/support), where you will find a bunch of new files created. Among them, you’ll find a few helper scripts, including apachectl, htpasswd (used to make Apache passwords for protected directories), and rotatelogs (its use is explained later). There are a few other files, but these are the most important.

Make a copy of these three files to your Apache binary directory. If you did not change the default settings, this would be located at /usr/local/apache/bin/.

To start the server, use

/usr/local/apache/bin/apachectl start

There is also

/usr/local/apache/bin/apachectl stop

and

/usr/local/apache/bin/apachectl restart

available, obviously to stop or restart the server.

To have Apache start upon booting up your system, make a copy of apachectl in your startup directory (typically /etc/rc.d/init.d or /etc/rc3.d/….)

Check it all out to make sure everything is working. From your browser, check out http://localhost/ right afterwards. You will know if it worked or not if you see anything….

Phew! Now that everything works, it’s time to configure our server.

Configuring Apache

Though it is generally thought to be scary to edit a configuration file for anything, for Apache, it doesn’t have to be. The configuration can be found in the apache_1.3.9/conf/ directory, and, though there are a bunch of files available, you only really need three of them.

Firstly, there is httpd.conf, which contains directives and configurations relating to the operation of the server as a whole. For example, server logs and server management.

Next on the list, there is srm.conf. This file contains the configurations for the management of resources in the filesystem, such as aliases, directory indexes, etc.

Lastly, access.conf. This file contains information on access control in whatever directories you please. All the other files, well you can just leave them be.

When you first install Apache though, the files are not named exactly like this, they seem to be named name.conf-dist. This means it is the distribution copy of the file. Since we like to have backup copies of anything and everything, just use a command similar to this (from unix)

cp httpd.conf-dist httpd.conf

Or, for windows, just copy the file, and rename it.

Another note, before we begin, you must restart Apache before any changes to the configuration files take effect. This is because the files are loaded upon initiation, so these changes will not be loaded otherwise.

Know your Directives

The Apache documentation can be extremely helpful for users just starting to configure their server.

At http://www.apache.org/docs-1.2/mod/directives.html, you can find a listing of available directives (configurations) for your server, with explanations as well. It should be noted though that the directives listed are for version 1.2, not the new 1.3 version. Most of them should be the same, but some may be gone, and new ones may exist.

Doesn’t sound like a tip? Well, it’s hard to configure something exactly for your needs without knowing exactly what it can do. So, with that said, this is definitely an important tip.

There is also a book available containing the directives. The Apache Web Server Installation and Administration Guide, which details the process of installing and administering the Apache Web Server, is a handy desktop companion. It also includes a printed version of the installation and general administration portions of the Apache documentation.

Knowing your directives can also make your life more convenient. If you don’t like where Apache has set your DocumentRoot (where you put your HTML and other files), you can easily change it in httpd.conf with this directive:

DocumentRoot /where/you/want/to/put/your/docs

Or if you want to set where e-mails are to be sent if there are server problems, just use this directive:

ServerAdmin you@your.address

Now that should be an excuse to get out and learn more… it will make your life easier.

Use Server Side Includes

When you don’t just want to serve your users plain old HTML, but don’t have the expertise yet to write up some CGI scripts (or are just lazy), try out Apache’s Server Side Includes (SSI).

So what is SSI?

Basically, it is an HTML document containing special commands within. If it is named appropriately, Apache will pre-parse the document when it is requested, and send the resulting document. SSI is controlled by the module named mod_include.

With SSI, you may do a variety of things, such as displaying some environment variables, displaying the date, or even including external files within your document.

Before you can use SSI, you must make sure the mod_include module was compiled with the rest of Apache. It is included by default, but you may have commented it out when editing Configuration.tmpl earlier. If that is the case, uncomment the line, and re-compile Apache. Once that is done, open up your httpd.conf file.

To use server-parsed HTML files, look for the section found below:

AddType text/html .shtml
AddHandler server-parsed .shtml

Make sure you get rid of the comments in front of the lines (the #’s), as they are commented by default. Notice how they use .shtml? You can change this to any extension you want really, you just have to remember to name your SSI files later with these extensions.

After you change these directives in the configuration files, restart Apache, and let’s make a test SSI file. Since we are using .shtml as our SSI extension, we will name our file test.shtml

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 3.2 Final//EN”>
<HTML>
<HEAD><TITLE> Test Server Side Includes </TITLE></HEAD>
<BODY BGCOLOR=”#FFFFFF”>
Current Date: <!–#echo var=”DATE_LOCAL” –>
<P>Document Name: <!–#echo var=”DOCUMENT_NAME” –>
<P>Environmental Variables:<BR>
<PRE><!–#printenv –></PRE>
</BODY>
</HTML>

If it looks right, and all your blanks are filled in, SSI is properly enabled on your server. Congratulations!

For more information on SSI, check out TheScripts.com’s SSI section at http://ssi.thescripts.com/.

Make those CGI’s Work

After you graduated from SSI, it’s time to setup your server to use CGI’s. CGI stands for Common Gateway Interface, but for some reason people always confuse it with Perl, the most popular language used for CGI. In fact, CGI can be any language really, such as C/C++, Java, TCL, or Perl, plus many others.

The module controlling CGI in Apache is called mod_cgi and is compiled by default. If you removed it from Configuration.tmpl though, you must add it back in, and re-compile Apache before you can proceed.

The first method of enabling CGI is to create a particular directory that contains scripts. A ScriptAlias is just like a normal Alias, except the documents are treated as applications, and not treated as documents when requested by the client.

A typical ScriptAlias setup looks like so

ScriptAlias /cgi-bin/ “@@ServerRoot@@/cgi-bin/”

This makes /cgi-bin/ an alias to your Server Root/cgi-bin/ directory. @@ServerRoot@@ reflects the ServerRoot variable you set near the top of the configuration file. You can write it any way really, such as

ScriptAlias /cgi-bin/ “/usr/local/apache/cgi-bin/”

or wherever you desire to put the cgi-bin directory. You would follow the above configuration with the following

<Directory “/usr/local/apache/cgi-bin/”>
Options ExecCGI
AddHandler cgi-script .cgi .pl
</Directory>

The AddHandler part allows you to have CGI scripts with .cgi and .pl extensions in this case. Here is the other method. This method allows you to use CGI outsite of ScriptAliased directories. You would use the following configuration;

AddHandler cgi-script .cgi .pl

Notice it isn’t found inside a Directory container? This way, the directive AddHandler applies to all of the documents, not just the documents found within a certain directory. Here, we allow .cgi and .pl extensions once again for our CGI scripts. You can use whatever.

CGI applications, when executed, are run under the same name as the user that owns the Apache server process. By default, the user is called ‘nobody’, as specified by the User and Group Directive. These directives can only work if the Apache server is started by the user root.

User nobody
Group #-1

In most cases, you won’t have to change a thing here. This is not always suitable though, as, if you have multiple users on your system, you might want CGI’s to run under the name of the user. This is excellent for virtual hosting systems, as you could have the CGI run under the customer’s name and access their files.

To counter this problem, Apache created the suEXEC program, included with the Apache server. To learn more about how to use it for your system, check out http://www.apache.org/docs-1.2/suexec.html.

Error Documents

Ever notice how some sites have their own error documents? For instance, try going here (http://www.thescripts.com/nopage.html). You get a 404 error, but not just any 404 error, we have a customized 404 error page. You can do this for any other error you can get as well (we also have a 403 error page). FYI, 404 errors mean the page was not found, and 403 means you do not have access to a particular document.

So how do we do it? It’s actually quite simple. Instead of using Apache’s default/kinda ugly error pages, you can specify certain files to be returned for certain errors. The directive being used here is called ErrorDocument, and below we find an example

ErrorDocument 404 /fourohfour.html

This is, as you might have figured out, the 404 error page. It is located in this case in the htdocs directory, and called fourohfour.html. If you accessed it from the browser, it would be at http://www.yoursite.com/fourohfour.html

To add another type of error document, for instance, 403, you would just do the following;

ErrorDocument 403 /fourohthree.html

So as you can see, the first argument in the directive ErrorDocument is the error number. The second is the location of the page.

Just a note, it would be best to use full image and link paths in an error document. This is because using relative links/image paths would be inaccurate. For instance, if you went to http://www.thescripts.com/nothere/nothere.html, the fourohfour.html page would be served as if it was located in the nothere directory, yet it is really in the root directory of your html documents. For more information on the ErrorDocument directive, visit http://www.apache.org/docs/mod/core.html

Content Negotiation

I know what you are thinking, what is content negotiation? Well, first of all, it’s an often overlooked feature of Apache. It is more accurately known as content selection, and is the selection of documents that best match a client’s browser capabilities, from one of several available documents.

Why do you need it?

Well, you don’t… but, if you are aiming your Website at a multi-lingual region, then having it would greatly be to your benefit. Not only will your documents be correctly served to the visitors, but it will also improve their stay at your site.
By default, content negotiation is compiled in with your server, as it is powered by mod_negotiation. If for some reason you didn’t compile this feature in with Apache, you must go back to your Configuration.tmpl file and put it back in.

Ok, what do you need now?

Well, you have to choose what languages you are going to be using, and have content available for both languages. There are actually two methods we can use: using a variants file, which can be found discussed here (http://www.apacheweek.com/features/negotiation), or, by using file extensions.

For this example, we will be using three different languages, English, French and German.

Now open up the access.conf file and let’s get started. Firstly, we will need to specify a directory, which we will call international, and have it so that it is set for content negotiation. The international directory will be located just off of the root document directory, which, in our case, is /usr/local/apache/htdocs/.

<Directory /usr/local/apache/htdocs/international>
Options MultiViews
</Directory>

Options MultiViews sets the directory so that the server does filename pattern matching to choose from among the results. Now, open up httpd.conf so we can add our languages to look for, and how the server will identify them. We will be using the directive AddLanguage

AddLanguage en .en
AddLanguage fr .fr
AddLanguage de .de

Here we have added English, French, and German, all identified with the extension found to their right.

By default, quite a few languages are already set. You can comment them out and add to them as needed.

The LanguagePriority directive allows you to give precedence to some languages in case of a tie during content negotiation. The languages are listed in decreasing order or preference.

LanguagePriority en fr de

So how do you name your files now? The best method is to do something like test.html.en for an English document, test.html.fr for a French document, and test.html.de for a German document. When you would like to link to this document, you just use test.html.

For more information on Content Negotiation, see http://www.apache.org/docs/content-negotiation.html.

A Single Config File

Geez, why would this help?

Well, it would put all your options into one single file, which makes life easy when you want to edit anything. In this case, we will use httpd.conf to store all of our directives. For some commentary on the three configuration files, see http://www.apache.org/info/three-config-files.html.

Anyways, back to the single config file issue. Right now you are using three configuration files: httpd.conf, access.conf, and srm.conf. You don’t need to. Simply empty the important stuff from the latter two files into httpd.conf, and then also add these two lines:

AccessConfig /dev/null
ResourceConfig /dev/null

This will inform Apache that httpd.conf is the only configuration file. With this in place, you can just simply remove the srm.conf and access.conf files, and proceed with a smile on your face.

Rotating Logs

So what are these log files you keep hearing about?

Every time a user requests a document from your site, the server ‘logs’ a record of this request into a log file. Log files contain vital statistics about users, such as their host, the date/time, and the request line, which contains browser information.

If your site is even remotely busy, or it’s just been a while since you’ve done anything to the logs, they will probably be rather large. Typically, they can reach many MB’s in a short period of time. Since the best application for log files is for log analysis with other software, large log files can slow down this process to a crawl.

So, what can you do about it? Use log rotation.

Log rotation is a procedure that takes a log file, puts its contents into a new file, and clears its own contents afterwards. Since its a rather boring procedure, there have been a few scripts to help you do it, including one from the Apache group itself.

One script, for example, is a small utility written to allow log files to be quickly split and processed. This utility will create a new log file for each day, and with the date as the extension. Once the new log file is created, the old one can be compressed or moved to a new location. The utility is called logbox, and is available from ftp://ftp.lemuria.org/pub/Code/logbox.tar.gz. You must compile it on your server before you can use it.

Another method of splitting files is made by the Apache group. Earlier you compiled it, which was also when you compiled apachectl and htpasswd. If you used the default settings, you also copied it to /usr/local/apache/bin/ afterwards. This program is called rotatelogs (how ingenious!), and it is used with the TransferLog directive in Apache.

In httpd.conf, add something like this:

LogFormat “%h %l %u %t “%r” %s %b “%{Referer}i” “%{User-agent}i””
ErrorLog /usr/local/apache/logs/error_log
TransferLog “|/usr/local/apache/bin/rotatelogs /usr/local/apache/logs/access_log 86400”

Let me explain this…

The directive LogFormat really isn’t anything to worry about actually. It just specifies the template format for how the access and error logs will look. For more information on the options LogFormat provides, see http://www.apache.org/docs-1.2/mod/mod_log_config.html.

ErrorLog sets the name of the file to which the server will log any errors it encounters. This is important to look over from time to time to see what might be going wrong with your site/server.

Now, to the part you’ve been waiting for.

The TransferLog directive. Here, we are mixing it up with the rotatelogs program at the same time. Technically, there is one argument to TransferLog here, but it can be broken down. The first part is the location to our rotatelogs program (in this case, it is at /usr/local/apache/bin/rotatelogs).

The second part is the location of our access_log file (The file in which we log our server requests, located at /usr/local/apache/logs/access_log). The last part sets the amount of time before rotating the log files. It is in seconds, and since 86400 seconds is equal to 1 day (24 hours), we rotate the file every day. You can set this to whatever time period you would like. The generated name of the old log file (after each rotation) will be /usr/local/apache/logs/access_log.nnnn in this case, where nnnn is the system time the log started at. After each rotation time, a new, empty log is started.

Get some Extras

Since Apache is open source, there are a ton of extras built for it. These extras can greatly enhance the performance of your server, and even give you more possibilities with your Website. Two of the most notable add-on’s include mod_perl, and mod_php

mod_perl is an excellent binding of the Apache Web server and Perl (http://www.perl.com/), the popular CGI scripting language. The module takes a copy of the Perl interpreter, and embeds it within Apache itself. This not only speeds up existing CGI’s, but it also allows you to write more modules in Perl itself. The Perl scripts are compiled once this way, unlike the usual method. Usually, the scripts are compiled on run-time by the interpreter, which makes them run a little slower from the start. If they are already compiled though, they start instantaneously, making this module an excellent addition to a Website with high levels of traffic.

mod_php is another great addition to Apache. The powerful server-side scripting language, PHP (http://www.php.net/), which is also open-source/free, can easily be linked with the server upon compilation. PHP scripts can be run like normal CGI’s, but this method allows them to be run at a much greater speed.

Both of these add-ons must be compiled in with Apache from the start though, as they are modules. If you would like to use them, just download them, edit your Configuration.tmpl file, run configure, and compile as usual.

There are instructions for these modules though, as they are a little more complicated. You can the documentation at http://perl.apache.org/ and http://www.php.net/ respectively.

Buy a Book

I must say this is the easiest place to find excellent tips. Not only are they always available to you (as it should be sitting next to you), but if you don’t have a laptop computer in the washroom, you can just read it there as well.
There are a few good books, and, as usual, my favourites are published by O’Reilly.

Apache: The Definitive Guide

This book boasts one of the members of the Apache development team. It begins with an academic discussion of what Web servers do before walking the reader through the process of installing Apache. The installation of Apache gets a lot of attention, and you are taught about Website security and other preferences.

Apache Server Bible

The Apache Server Bible is an excellent guide to administering your Apache Web server, and is aimed at those with no previous Web administration experience. Topics include compiling source code, installation, configuration issues.

Apache Server for Windows Little Black Book: Little Black Book

This book will show you how to put Apache’s capabilities to work. The book even moves on to things like CGI, database management, encryption and more.

Optimize your Apache Server

Once your Website becomes popular, you will have to start worry about another issue: how to get the most out of your server. With the traffic loads pounding it constantly, you will have to find a way to optimize it to handle the traffic a bit better.

That is where this part of the tutorial comes into play. Before we begin, I must state that all of these tips will be aimed at unix servers, as Apache is not optimized for Windows at all.

When looking at speed issues and Apache, we must look at the hardware/operating system, your configuration files, and how you compiled the server from the start. For those of you that want to read all of your performance options, check out http://www.apache.org/docs/misc/perf-tuning.html and http://www.apache.org/docs/misc/perf.html. Also you might want to check out the O’Reilly book, Web Performance Tuning.

File Lookups

This is something you might not have even thought of. The two culprits here are simply .htaccess files and symbollic links. For those of you that are looking at the page funny, .htaccess files are a type of access control file. They can contain Apache Directives, and apply to the directory they are in and everything below it, overridden only by other .htaccess files.

By default, the Apache Directive AccessFileName is set to .htaccess, so it is known as that unless you changed it. So you can really think of it as just another Apache configuration file, though it is optional.

When returning a document to the client the server looks for an access control file with this name in every directory of the path to the document, if access control files are enabled for that directory. For example, say I was getting a document found at http://www.mysite.com/test/test2/test3/test4.html and my DocumentRoot directive was set to /usr/local/apache/htdocs. Apache would look for an .htaccess file in the following directories;

/
/usr
/usr/local
/usr/local/apache
/usr/local/apache/htdocs
/usr/local/apache/htdocs/test
/usr/local/apache/htdocs/test/test2
/usr/local/apache/htdocs/test/test2/test3

Do you see what I’m getting at?

With access control files enabled, Apache has to do quite a bit of checking for unnecessary files, which robs you of some performance.

So how do we fix this problem?

We can use the Directory container to specify no overrides are acceptable within the container. In this case, we use the root directory.

<Directory />
AllowOverride None
</Directory>

After that, we may want to be able to still use .htaccess files. If this is the case, you can enable them again,

<Directory /usr/local/apache/htdocs>
AllowOverride All
</Directory>

And there you go. The AllowOverride directive has a few options actually, to see them, check out http://www.apache.org/docs-1.2/mod/core.html.

Symbollic links have a similar issue, and the fix is nearly the exact same, except different directives are used.

<Directory />
Options FollowSymLinks
</Directory>

Followed by

<Directory /usr/local/apache/htdocs>
Options -FollowSymLinks +SymLinksIfOwnerMatch
</Directory>

Now we got rid of the file lookup problem, as there are no unnecessary file checks.

Hostname Lookups

Apache, by default, has the directive HostnameLookups set to off. This is a good thing, as, with it on, each client request to your server would result in a lookup request to the nameserver.

This is also a problem if you are restricting access to particular sections of your site with the order directive, accompanied by allow and deny. It is best if you use IP addresses in this case, as otherwise, you have to do another nameserver lookup.

With that out of the way, your Apache server doesn’t have to do any unnecessary DNS stuff, and can stick to it’s job. If your CGI’s, PHP or whatever else might require using hostname lookups, you can use a file container to specify this.

<Files ~ “.(php3|cgi)$>
HostnameLookups on
</Files>

Content Negotiation

Here I go again with my fancy words, content negotiation. I know I suggested using it earlier, but that’s only if it would benefit you. Otherwise, you should stay away from it. Why? Since it requires searching for particular files, and not exact names, the searching part puts a little more load on the server, therefore slowing it down just a tad. Also, for directives that ask you for files, such as DirectoryIndex, instead of just putting index, put the actual file name. The example is below;

DirectoryIndex index

Index is a wild card, as there is no extension specified, and it has to do some searching again to find the file. Putting a list of names would be a much quicker, more efficient method. Put the most common name first, and in descending order.

DirectoryIndex index.html index.shtml index.cgi

Hardware

As with most software, Apache needs RAM, especially if you get a lot of traffic. If it gets to the point that your operating system has to start swapping memory, with the hard drive, you must either get more RAM or set the directive MaxClients a little lower.

Swapping memory isn’t necessarily slow, but for the client, it is. They will get irritated, hit stop-reload a few times, and further the load on your server. Not a good thing.

Besides that, with a fast enough hard drive, network card and CPU, your server should perform quite well (hardware-wise at least). With a little experimentation, you should be able to find an optimal configuration.

Server Processes

Settings such as MinSpareServers, MaxSpareServers, StartServers, and KeepAliveTimeout (if KeepAlive is set to ‘On’). The SpareServers directives instruct the server how many ‘child’ processes to create. Apache uses these directives to determine the load it has to adapt to.

If your server has children waiting for requests, and the amount exceeds the MaxSpareServers setting, some of those child processes will be killed. If the amount is less than MinSpareServers, some child processes will be created.
The settings of these directives will directly relate to your server performance. If you don’t have enough child processes to handle the current server load, some requests will be delayed, causing your server to be slower. Too many processes will also slow down your server, if you don’t have enough RAM and CPU power to handle it.