Optimizing PHP, Part Three

This article shows you how to configure and compile PHP for maximum performance.

Last month’s “Tech Support” column showed you how to install and configure the Alternative PHP Cache to speed up your PHP applications without changing any code. This month, let’s go one level deeper in the stack and tune your PHP installation itself.

While pre-packaged binaries are convenient, high-traffic sites typically need a roll-your-own PHP and Apache to fine-tune features and yield extra performance. Start with the latest version of PHP. The 5.1x branch has finally brought PHP 5 performance up to an acceptable level, and includes many advances over PHP 4. After downloading and unpacking the latest version of PHP 5 (5.1.4 as the magazine went to press), set your CFLAGS, an environment variable for compiler flags that are passed to gcc. The correct compiler flags depend on what kind of machine you have, what kind of CPU you have, how much cache the CPU has, and a variety of other factors.
Here are two examples, the first for the Xeon processor and the other for the Opteron.
$ export CFLAGS="–march=pentium4 –O3 \
–pipe –msse2 –mfpmath=sse,387 \
–mmmx –fomit-frame-pointer \
$ export CFLAGS="–march=opteron –O3 \
–pipe –msse2 –m3dnow \
–fomit-frame-pointer –mtune=opteron"
The one major difference between the two commands other the obvious architecture (–march) variance, is the –prefer-non-pic option, which tells the build process to build a non-PIC version of libphp. Non-PIC, or position-independent code, is only supported on the x86 architecture in conjunction with certain platforms such as Linux and FreeBSD, and provides a roughly 10 percent performance boost if you’re running PHP as an Apache DSO.
With your build environment set, you can run configure to prepare for the buid. There are many configure options available in PHP. You can see all of your choices with the command ./configure ––help. Next, consider which options you need, limiting yourself to the bare essentials that meet your requirements. This ensures you have the leanest PHP binary possible. For example, if you’re certain you’ll never use the IPV6 features of PHP, specify the ––disable-ipv6 parameter.
When you’ve pruned all but the necessary options, add ––enable-inline-optimization ––disable-debug to your configure parameters and continue. You can now run make&&make install as normal. After the build is done, you can optionally run strip libphp5.so to strip the debugging symbols and significantly reduce the size of the binary.
Once you’re comfortable compiling PHP, feel free to experiment. Make sure to closely monitor your system load and performance between tweaks, so you can note what changes worked and which ones you need to roll back. Keep in mind that a large amount of tweaking is required only if your site has significant traffic. If you fall into that category, you may be surprised just how much of a difference you can achieve with a little work.
Of course, the disadvantage of a custom-built PHP is increased maintenance. An upgrade to a new version of PHP is no longer as simple as installing the latest PHP packages with yum or apt-get. However, if you keep copious notes and capture much or all of the build process in scripts, you can repeat your efforts much more reliably and quickly.
If you want more information about compiling PHP for best performance, http://talks.php.net/index.php/Performance is a great place to start.
Hopefully, this and the previous two “Tech Support” columns have provided you with impetus and information to accelerate your PHP and thus, your Web site. By combining all three techniques, you may be amazed by PHP’s newfound swiftness. The techniques described here have allowed LinuxQuestions.org to scale well on very modest hardware.
Look for further LAMP tweaks in future versions of “Tech Support.” In the meantime, if you have a great PHP tip you’d like to share, send email to the address below.

Jeremy Garcia is the founder and administrator of the recently redesigned LinuxQuestions.org, a free, friendly, and active Linux community. Please send questions and feedback to class="emailaddress">jeremy@linuxquestions.org.

Comments are closed.