FastCGI was the answer. With PHP as a module installed every Apache process can take up to the maximum amount of memory you defined in php.ini plus what the Apache process needs by himself even though this process is only serving static content. With the switch to FastCGI it was possible to use the threaded version of Apache (mpm_worker). Static contents are now served really fast without need for invoking PHP at all. PHP scripts are served by calling the FastCGI IPC.

As memory is still low Apache and PHP are both configured to “die” after quite a low number of requests served. This can sometimes lead to a small delay while the processes are restarted but ensures that the memory footprint is kept low.

How did I do it? I won’t go into details on how to install Apache, mod_fcgid and PHP because there are loads of howto’s out there. Please find the configuration I’m using below. I’m using Debian and Apache, mod_fcgid and PHP are installed out of the repository. If you have a custom compiled version or different distribution your paths can differ.

Depending on your available hardware it is feasible to tweak the settings for the mpm_worker module so more concurrent clients can be served and/or the amount of requests which is handled before re-creating the thread is higher. It is also very recommended to use eAccelerator in conjunction with this setup. See my post on the topic for more information.

/etc/apache2/apache2.conf (excerpt):

<IfModule mpm_worker_module>
	StartServers           4
	ServerLimit            4
	MaxClients           128
	MinSpareThreads        8
	MaxSpareThreads       16
	ThreadsPerChild       32
	MaxRequestsPerChild  500
</IfModule>

/etc/apache2/mods-available/fcgid.conf:

<IfModule mod_fcgid.c>
	AddHandler fcgid-script .fcgi .php
	FCGIWrapper /var/www/php-fcgi-starter .php

	IdleTimeout		3600
	BusyTimeout		 300
	ProcessLifeTime		7200
	IPCConnectTimeout	  10
	IPCCommTimeout		 360
	MaxProcessCount		  15
	MaxRequestsPerProcess	  -1
	PHP_Fix_Pathinfo_Enable    1
</IfModule>

/var/www/php-fcgi-starter:

#!/bin/sh
PHPRC=/etc/php5/cgi/
export PHPRC
export PHP_FCGI_MAX_REQUESTS=250
export PHP_FCGI_CHILDREN=1
exec /usr/lib/cgi-bin/php

I allready use WebDAV in combination with Subversion. DAV is an extension to the HTTP protocol which allows you also to upload files onto the webserver. This makes FTP useless and with some tricky tools it also integrates quite nicely in your desktop environment.

I have a 2 tier setup. At home my server features a Apache2 with enabled WebDAV. Configured as follows:

Alias /share /path/to/your/files

<Location /share>
	Header add MS-Author-Via "DAV"

	BrowserMatch "^WebDAVFS/1.[012]" redirect-carefully
	BrowserMatch "Microsoft Data Access Internet Publishing Provider" redirect-carefully
	BrowserMatch "Microsoft-WebDAV-MiniRedir/5.1.2600" redirect-carefully
	BrowserMatch "^WebDrive" redirect-carefully
	BrowserMatch "^WebDAVFS" redirect-carefully

	DAV on
	AuthType Basic
	AuthName Share
	AuthUserFile /path/to/your/.htpasswd
	Require valid-user
</Location>

And on my Windows XP PC there is a nice tool from Novell running called NetDrive. As this tool could not be provided by Novell directly due to license issues I put it here for download (they especially mention to look for netdrive.exe on Google. So I think it shouldn’t hurt ).

With NetDrive you can mount the share like a network share as a normal drive and also can access it as such. With this solution you have all-time access to you files without need for any kind of strange solution which can issue other problems like NAT for instance.

But I figured there has to be something to make the apache2 faster that it is out-of-the-box on a Debian Etch system. I wanted to use mod_fastcgi to link PHP and use mpm-worker for apache2 but due to a lack of time I failed. Later I discovered it was only a matter of permission which prevented this. Due to mod-php5 I couldn’t use mpm-worker but had to use mpm-prefork the slower variant.

With this in mind I thought “lets check the apache2 docs and check if there is something we can do about this”. So I discovered the following directives which can fasten up things a little bit:

BufferedLogs On
EnableSendfile On
HostnameLookups Off

BufferedLogs is an experimental directive which prevents Apache2 to write logs directly to the disk but keeps them in memory and write them in a bunch. This should minimize the write overhead for each access so the access itself is faster.
With EnableSendfile you tell apache2 to use the sendfile method from the Kernel for static files which should prevent apache2 to read the file itself so reducing the readoverhead for static content.
HostnameLookups is off by default on Debian Etch. I don’t know how it is on other distributions. The command prevents apache2 to make an lookup for the ip from the visitor. When your nameserver is slow or no hostname can be resolved this could slow your system down incredibly. (In my expirience 70% all the problems with databases or webserver are DNS problems).