Tuning Apache and PHP for Speed on Unix

To tune well, you need to benchmark your Web server. You can get some benchmark figures using ApacheBench
(ab) or httperf
. If you are an OS agnostic like me, I recommend using Microsoft's excellent free Web Application Stress Tool
(WAST - requires M'soft Windows). WAST is more flexible than ab
because it allows you to define different GET parameters for each
thread. This is important because it allows you to simulate multiple PHP
sessions via the PHPSESSID GET parameter. Avoid benchmarks involving
PHP sessions when using ab as the sessions will become an artificial
bottleneck. More info on using WAST with PHP
.

To monitor the Apache server, I use the command

top d 1

which displays CPU and memory usage of all processes on the machine, and

apachectl status

.

 

General rule of thumb for hardware upgrades
: For PHP scripts, the main bottleneck is the CPU
. For static HTML/images, the bottleneck is RAM
and the network
.
According to Compaq benchmarks in 1999 (the original article is lost
due to bitrot), a slow 400 Mhz Pentium can saturate a T3 line (that's
45 Mbps) with static HTML pages.
 

A PHP script will be served at least 2-10 times slower than
a static HTML page by Apache. Try to use more static HTML pages and
fewer scripts.
 

Enable the compression of HTML by putting in your php.ini:

    output_handler = ob_gzhandler

If you think about it, it might take you 0.1 seconds to generate 40K of
HTML in your PHP page. However it probably takes 6 seconds for the user
to download the page using a 56k modem without compresson. With
compression, the download will probably take 2-3 seconds.

So the time taken for page generation is miniscule in comparison to the
transit time of the HTML from the server to the browser. Therefore the biggest speedup you can perform for modem users is using ob_gzhandler

!
This feature is only recommended for PHP 4.1.0 or later. This point was
moved closer to the top of the list on 9 July 2002 when i personally
experienced the benefits of compression. More info...

 

Your PHP scripts are recompiled every time unless the scripts are cached. Install a PHP caching product (I recommend Turck MMCache
) to typically increase performance by 25-100% by removing compile times.
 

Switch from file based sessions to shared memory sessions. Compile PHP with the --with-mm
option and set session.save_handler=mm
in
php.ini. Informal benchmarks suggest that session management time is
halved by this simple change. Added 1 Dec 2001. This hint should only be
used for PHP 4.2.0 and above as there were bugs before this.
 

An alternative caching technique when you have pages that
don't change too frequently is to cache the HTML output of your PHP
pages. Try Smarty
or Cache Lite
.

Use output buffering (See ob_start
).
This will speed up your PHP code by 5-15% if you frequently print or
echo in your code. Note that output buffering is already enabled if you
are using the above ob_gzhandler hint. ASP does this in IIS 5. Added 26
Nov 2001.
 

On Windows, FastCGI

is the highest performance way of running PHP with Apache. Although PHP4
can run in a threaded environment, some global locks prevent it from
making full use of threads. Also PHP is not very stable in threaded
environments because many common extensions are not thread-safe. Added Feb 2004
.
 

In PHP4, objects and arrays should be passed in and out of
functions by reference (with &), and everything else by value. In
PHP5, objects are automatically passed by reference. For example the
following gives best performance:

function &test(&$obj_or_array)

{

return $obj_or_array;

}

$var =& test($obj);

 

Be miserly and sparse with your server and web pages. Don't run X-Windows on the server and other unneeded processes. Apache Today
has a guide on how to remove them.
 

Don't use images when text will do. Reduce your image sizes
with a software like Adobe ImageReady or MacroMedia Fireworks. Avoid
dithered images as they tend to compress poorly.
 

Spread the workload. Run your SQL server on another
machine. Serve graphics and HTML from another low-end computer. If all
static content is served from another server, then you can turn off KeepAlives
in httpd.conf on the PHP server to speed up disconnects. 1 Feb 2002: I am currently using tux
as the static web server, and have set it to pass all .php files to Apache which resides on the same machine.
15 March 2002: thttpd
is another popular static web server.
 

Use hdparm
to tune your hard disk. If you are using a default Linux install, this
could speed up your hard disk by 200%. This is mostly useful for IDE
hard disks, but some hdparm settings work with SCSI also.
 

Modify the following httpd.conf parameters to:

# disable DNS lookups: PHP scripts only get the IP address

HostnameLookups off 

# disable htaccess checks

<Directory />

AllowOverride none  

</Directory>

and turn on follow FollowSymLinks and turn off SymLinksIfOwnerMatch
(correction by Joshua Slive) to prevent additional lstat() system calls
from being made:

Options FollowSymLinks

#Options SymLinksIfOwnerMatch

There are many other httpd.conf tips below.

EnableSendfile On
  //default is on

ExtendedStatus off
  //default is off

the minimal list of modules which you can get by with tends to include mod_mime, mod_dir, and mod_log_config.
you can select a faster atomic
implementation at build time by configuring Apache with
the

--enable-nonportable-atomics

option:

./buildconf

./configure --with-mpm=worker --enable-nonportable-atomics=yes

Ideally you should run servers without multiple Listen statements if you want the highest performance.

KeepAlives and lingering_close are the main slowdown points for Apache processes; getting rid of one will  speed up Apache a bit, whereas getting rid of both will have a much more dramatic effect.

If you are comfortable patching Apache 1.3 sources, try lingerd
.
Each Apache process currently wastes a lot of time "lingering" on
client connections, after the page has been generated and sent. Lingerd
takes over this job, leaving the Apache process immediately free to
handle a new connection. As a result, Lingerd makes it possible to serve
the same load using considerably fewer Apache processes.
 

Increase your kernel's tcp/ip write buffers so that most, if not all generated pages can be written without blocking.  If the page that  Apache generates fits in this buffer, then Apache's write() call returns instantaneously, then Apache hands the socket over to   lingerd, logs the hit, and is immediately free for more work.  If the  page doesn't fit, then write() blocks until the client has acknowledged part of the data, which can take several seconds.

To change this, use the SendBufferSize directive from httpd.conf.  However, this directive cannot increase the buffer size past the  kernel limit.  Changing this kernel limit is OS-specific.

Under Linux you can set it by echo'ing a larger number (eg. 131072)  into /proc/sys/net/core/wmem_max, before starting Apache.  If you  change wmem_default as well as wmem_max, then the SendBufferSize  directive is not needed.

If you're handling extremely high loads (500 connections per second and above on a single machine), make sure that the hard limit on open  descriptors for the lingerd process is high enough (it should be at  least twice the peak number of connections per second)

On Linux, the hard limit for a given process can be set (eg. to 2048)  by running the bash command "ulimit -H -n 2048" as root, and the system-wide total of available descriptors can be set by echo'ing a number into /proc/sys/fs/file-max.

Lingerd regularily sends some statistics to syslog, including the  number of open file descriptors in use.

If you are a brave soul, you can also apply Silicon Graphics' Accelerated Apache
patches. "This project's aggressive optimizations make Apache/1.3 up to
ten times faster and Apache/2.0 up to four times faster on the
SPECweb96 benchmark."
 

Sascha Schumann of the PHP development team recommends compiling PHP4 with the following settings
--enable-inline-optimization --disable-debug
 

Set the noatime attribute for frequently accessed files.
Otherwise Unix systems will record the last file access time. This is a
useful setting for your web pages. Here's how to change in on Linux
and Solaris
. Added 14 March 2002.
 

Use a Ramdisk to store your temporary files (e.g. session variable files). Ramdisk howto
.
Mr Perkins points out that for Linux 2.4/Solaris, rather than
creating a ramdisk, using tmpfs is more effective as it won't ask for
all the ram straight away, and also if the machine becomes very busy the
ram is freed and swap is used. The following command sets up the
filesystem over your existing /tmp (where php stores cookie info by
default):

 

mount tmpfs /tmp -t tmpfs -o size=64m

I just realised that all the above tips deal with
squeezing the maximum performance from a single server. Ultimately if
you are successful, the tips won't be enough. Then you will need to
switch to using multiple Apache servers (a server farm) with clustering
, load-balancing
and caching
. Using Squid
as a proxy cache. Configuring
Squid. Rasmus Lerdorf recommends squidGuard
(added 30 July 2002).
 

Deprecated is the recommendation to use Apache 2 with
threaded PHP SAPI. Apparently PHP still has some global locks that
prevent it from maximizing concurrency with multiple threads. Modified Feb 2004
.
 

 

PHP Specific Articles

- High Performance PHP presentation
by George Schlossnagle given at PHPCon 2002

- Advanced PHP presentation
given by Sterling Hughes and Andrei Zmievski at O'Reilly Open Source Conference 2002.

- Optimizing PHP
article by John Lim.