« Pruning Your Email List | Main | Network Statistics »

Apache web server performance

Back in December I noticed problems with timeouts while trying to connect to our website. I could secure shell into the server with no problem. I ran top and noticed no processes running amok and CPU usage was low. There were some httpd Apache server processes running. I could also login to the Plesk control panel. Everything looked ok.

I opened a ticket with our host provider and found out that I needed to learn how to tune my Apache web server.

Our VPS provider checked out our server and noticed that we had 160 connections to our Apache web server. They made use of the shell command:

netstat -alnp | grep :80 | wc -l

They recommended I increase my max clients setting and reduce my timeout setting in httpd.conf. My first action was to Google httpd.conf and read up a bit on Apache configuration parameters. I found the Apache website to be very useful, especially the Apache Performance Tuning page, and the page on prefork which describes how the Max Clients parameter is used to control how many child processes are created to handle incoming requests (for a non-threaded server).

My original settings were:

Timeout 120
KeepAlive Off
MaxKeepAliveRequests 100
KeepAliveTimeout 15
<IfModule prefork.c>
StartServers       1
MinSpareServers    1
MaxSpareServers    5
ServerLimit       10
MaxClients        10
MaxRequestsPerChild  4000
</IfModule>

I made the following changes to /etc/httpd/conf/httpd.conf

Timeout 60
<IfModule prefork.c>
StartServers       5
MinSpareServers    5
MaxSpareServers   10
ServerLimit       30
MaxClients        30
MaxRequestsPerChild  4000
</IfModule>

I then restarted the httpd (Apache) server. You could use Plesk to do this, or the shell command service httpd restart. This resolved my immediate problem.

Note: based on more research I suspect the timeout parameter didn't need to be changed, I haven't noticed a problem with clients holding connections. This was mostly just a higher load on the server than we were used to. On the other hand it probably can't hurt so I've left it as is.

At about the same time I decided to try some other changes. I also made the following performance related changes to help pages load faster. It keeps the client connection open to handle subsequent requests. Initially I thought this made our page loading somewhat faster. We have a bunch of small images used for navigation and some css files, and some pages have multiple content images.

KeepAlive On
MaxKeepAliveRequests 80
KeepAliveTimeout 5

I made it smaller than it's original setting since I didn't want too many unused connections hanging around. I didn't notice much change in perceived page loading or in the network statistics. I then turned KeepAlive Off, and it didn't seem to make much of a difference. But since it doesn't seem to be a problem, and it might help, I turned KeepAlive back on.

Early in March 2008 I noticed that things seemed to get slow again. I did a little more research on Google and found a method of telling if your MaxClient setting is too low.

grep -i maxclient /var/log/httpd/error_log*

I found a couple of messages in error_log indicating the maxclient setting had been reached. So I increased the setting from 30 to 60. I also set MaxSpareServers to 20 so that we would have 20 httpd processes waiting to handle any traffic surges, and MinSpareServers at 5 so that more spares are created if we start to get busy.

StartServers       20
MinSpareServers    5
MaxSpareServers   20
ServerLimit       60
MaxClients        60

I was concerned about too much memory use. But I checked afterwards and I'm only using about 100mb of RAM, and my VPS allocation is 512mb. So I think things should be good for awhile.

But all this got me thinking that I need to monitor these sorts of things more closely. I started by adding /var/log/httpd/error_log to my daily log scan process so that I'll catch the next maxclient exceeded message. I also rebuilt my /proc/net/dev reporting process to show bandwidth used, number of httpd processes, and various netstat statistics which will be the subject of my next post.


© 2016 Mike Silversides

About

This page contains a single entry from the blog posted on March 27, 2008 7:59 AM.

The previous post in this blog was Pruning Your Email List.

The next post in this blog is Network Statistics.

Many more can be found on the main index page or by looking through the archives.