As we know from the previous article, Ubuntu Intrepid uses a different layout from other non-Debian based systems - let's move on and take a look at the main apache2.conf and ports.conf.

We're not actually going to change a lot at this point, just look at the main settings and see what they mean and what a change will actually do.

Defaults

Why no specific changes to the default?

Well, it's difficult to give a definitive configuration as there are so many variables to consider such as expected site traffic, Slice size, site type, etc.

Remember that it is very unlikely the default Apache configuration will be ideal for your Slice. Don't be intimidated by the thought of 'optimising' the install - following the next couple of articles will allow you to understand the meaning behind the concepts.

You'll also find the same things apply to any web server - they may call them different things, but the concepts remain the same.

My advice is very simple: experiment. Find what works best on your setup.

Well, that seems fair enough. Port 80 is the standard HTTP port to listen on and if you have the ssl module loaded, then it will also listen on port 443 (HTTPS).

Also, name based virtual hosts are enabled by default, for HTTP requests made on all interfaces (*) on port 80, per the NameVirtualHost directive. Note the comment concerning the lack of support for SSL name based virtual hosts — in practical terms this means that you will need an additional public IP assigned to your Slice for each additional SSL-enabled site that you intend to host on the same Slice.

Configuring Apache to listen on another port, say 8080, is as simple as adding:

Listen 8080

Once that is added to the file and Apache restarted, it would listen on port 8080. You would want to change the port specified in the NameVirtualHost directive to match.

apache2.conf

now open up the main Intrepid Apache config file:

sudo nano /etc/apache2/apache2.conf

I won't list the contents here but, if you are not familiar with the settings, have a read of the comments. I find them very informative and straight to the point.

You may be surprised how well config files are documented. I always recommend giving them a read - sure, they may not make a lot of sense to begin with but as time goes by you will be able to glance at them and know what to change.

Anyway, let's look at some of the main settings and what they mean:

Timeout

Default:

Timeout 300

This sets (in simple terms) the maximum time, in seconds, to wait for a request, action it and the response to the request.

The default is deliberately set high to allow for varied situations. You can reduce this to something more sane, such as 45 or even lower. A decrease may also help in reducing the effects of a DOS attack.

KeepAlive

Default:

KeepAlive On

Keep this set at 'On' as it allows for persistent connections to a client so each file, image, etc is not requested with a new connection. This allows for more efficiency. Define the KeepAlive settings as shown below:

MaxKeepAliveRequests

Default:

MaxKeepAliveRequests 100

Now we have our persistent connection, set the maximum number of requests per connection. Keep this high more maximum efficiency. If you have a site with lots of images, javascripts, etc, try increasing this to 200.

KeepAliveTimeout

Default:

KeepAliveTimeout 15

So how long does the persistent connection wait for the next request? The default setting is very high and can easily be reduced to 2 or 3 seconds. If no new requests are received during this time the connection is killed.

What does this mean? Well, once a connection has been established and the client has requested the files needed for the web page, this setting says "sit there and ignore everyone else until the time limit is reached or you get a new request from the client".

Why would you want a higher time? In cases where there will be a lot of interactivity on the site. However, in most cases, people will go to a page, read it for a while and then click for the next page. You don't want the connection sat there doing nothing and ignoring other users.

prefork MPM

During the Ubuntu Intrepid Apache install we selected apache2-mpm-prefork and not apache2-mpm-worker. If you want to know more about the differences between the two I will point you towards the official Apache docs (which are actually very good).

Again, it's difficult to give a suggestion here as to what is best for your site but have a read of the definitions below and see if anything could be improved when you consider what your site(s) serves.

MaxSpareServers: maximum number of child server processes not doing anything (idle) — any more than the maximum will be killed.

Don't set Max lower than Min, but Apache will ignore silly numbers here and set the Max at Min+1.

MaxClients: sets the maximum simultaneous requests that Apache will handle. Anything over this number will be queued until a process is free to action the request.

MaxClients is not the same as the maximum number of visitors you can have. It is the maximum requests.

Remember the KeepAliveTimeout? This was set low so the next request can be actioned and the original (now 'idle') client will still be sat there reading your webpage — the new (active) request will be actioned or, if the MaxClients limit has been reached, will be queued ready for the next available process.

In most cases, the client is not 'active'. Take this page, for example: you requested it (using an active process) and then spent a while reading it which uses no processes — you are 'idle' (as far as the server is concerned!).

MaxRequestsPerChild: sets how many requests a child process will handle before terminating. The default is zero, which means it will never die.

Why change this if the Max numbers are set as shown above? Well, it can help in managing your Slice memory usage.

If you change the default you give a child a finite number of actions before it will die. This will, in effect, reduce the number of processes in use when the server is not busy. Thus freeing memory.

Freeing it for what though? If other software needed memory then it would also need it when the server is under load. It is unlikely you will have anything that requires memory only when the server is quiet.

Summary

Quite a lot here, but as you go through the different settings you will see that the theory is quite simple. Naturally, there is a lot more to it than this article (or set of articles) can go into.

In the second apache2.conf article, we will look at other settings that will add some more efficiency and help in increasing the security of our Slice.

—

Mike

Article Comments:

Very good overview - just like the last several articles. The quality of the documents here is the reason that I think it's time I purchases some slices. It get even better - I can apply this to the non-linux world as well!

I'm so grateful to you for that articles about Linux based systems cause I've recently reinstalled Ubuntu Linux on my PC and don't regret at all- it has a great number of advantages.I did it several months ago but had some system crashes cause the version of the system seemed to be unstable during the setup.Thanks!

Vinay commented Wed Jul 07 06:38:47 UTC 2010:

I noticed that you have suggested a setting of 150 for MaxClients here while leaving ServerLimit to its default of 256.

I recently came across this in the Apache docs on ServerLimit - "With the prefork MPM, use this directive only if you need to set MaxClients higher than 256 (default). Do not set the value of this directive any higher than what you might want to set MaxClients to."

So the setting in this article is contradictory to what the Apache docs suggest above - ie. not to set ServerLimit higher than MaxClients.

Im curious to know why you think this is a generally good setting for most users.

The docs also say, as you quoted, that you should only tinker with that directive if you need to set it higher than 256. When MaxClients is lower than ServerLimit, MaxClients does take priority (essentially, the priority is the lower of the two). The primary difference between the two directives is that ServerLimit is more hardwired - it takes a full restart to implement a change to that setting, while MaxClients can be changed with a simple reload (graceful restart).

ServerLimit comes into play more when you want to use it as a failsafe limit - with another MPM like worker, one might inadvertently set MaxClients to a number that requires more server processes than you think the VPS can handle, so ServerLimit would make sure that even with a higher MaxClient number the actual number of server processes won't be enough to start swapping.

Speaking of high...the default MaxClients of 150 is likely high if your server has less than 1 GB of memory available to it. I haven't linked it here because I haven't tested it with intrepid, but this article goes into a little more depth on MPM tuning (though admittedly, it's not a true tuning guide - it's an adaptation of this article with some advice thrown in, really).

Oh, and I should add, to clarify: The settings displayed for the prefork MPM in this article aren't recommendations, they're just the default. If you install the apache2 package (which is installed from Ubuntu's repository), those are the settings in apache2.conf by default. So ServerLimit is not set in the default configuration of apache (and if I remember correctly, the MPM defaults in the config file are the same if you install apache from source).

Vinay commented Sun Jul 11 02:58:59 UTC 2010:

Jered, thank you for clarifying this. I asked because Im trying to put together a series of blog posts on server tuning for rails apps and I just wanted to be sure im clear about everything. So the article on MPM tuning will be useful definitely! :)
The first part of the series is here btw - http://ahref.in/55599 . Thanks again!