LinuxQuestions.org
View the Most Wanted LQ Wiki articles.
Go Back   LinuxQuestions.org > Articles > Jeremy's Magazine Articles
Reload this Page Optimizing PHP, Part Three
User Name
Password

Notices

By jeremy at 2006-09-23 11:05
Optimizing PHP, Part Three
Features - Power Tools
Written by Jeremy Garcia

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.1.x branch has finally brought PHP 5 performance up to an acceptable level, and includes many advances over PHP 4.x. 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.

Code:
$ export CFLAGS="–march=pentium4 –O3 \
  –pipe –msse2 –mfpmath=sse,387 \
  –mmmx –fomit-frame-pointer \
  –prefer-non-pic"
Code:
$ 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.
‹ Optimizing PHP, Part OneupOptimizing PHP, Part Two ›

by TGoddard on Thu, 2006-10-12 02:49
I find it disappointing that this article talks about performance tuning but fails to discuss the tradeoffs being made by the options given.

I am particularly alarmed by the --prefer-non-pic argument as this is a very serious CPU/memory tradeoff. If used incorrectly and in the wrong circumstances it can cause serious delays with memory consumption and library loading time due to the need for relocation. What scripts did you get the 10% improvements for? You might on a complicated CMS script but I would doubt you would get sufficient benefit for a simple database-driven page.

Note that I'm not a PHP guy at all - this is just a general comment on compiling any application that may have many CGI instances running at once without PIC code. There may be an improvement after all, but it would be nice to see the benchmarks and what circumstances are most appropriate.

EDIT: On rereading the article I noticed your condition "as an Apache DSO" attached. Sorry for misreading it. Non-PIC code may perform well under these circumstances.

by jeremy on Mon, 2006-12-04 20:26
Thanks for the feedback. That DSO bit is a very specific requirement for the '--prefer-non-pic' and it's actually a default on x86 machines in newer versions of PHP. As for the "simple database-driven page", by the time you need to do any kind of in-depth optimization like this, you should have a high traffic site that has much more than simple database-driven pages.

--jeremy


  



All times are GMT -5. The time now is 08:55 AM.

Contact Us - Advertising Info - Rules - LQ Merchandise - Donations - Contributing Member - LQ Sitemap -
Main Menu

My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: @linuxquestions
Open Source Consulting | Domain Registration