Slashdot Mirror
Optimize PHP and Accelerate Apache
An anonymous reader writes "As the load on an application increases, the bottlenecks in the underlying infrastructure become more apparent in the form of slow response to user requests. This article discusses many of the server configuration items that can make or break an application's performance and focuses on steps you can take to optimize Apache and PHP."
want performance from php?
Dump Apache! its the slowest link!
use Lighttpd + latest PHP 5.2.2 + APC
Apache generally ships (on most distros) with TONS of modules enabled... kill off any unneeded modules (come on, how many of you actually use mod_userdir or mod_rewrite?), tweak your MPM settings, and be done with it.
I also force PHP to run in FastCGI mode, that way I can use suExec with it to prevent exploits in PHP itself from allowing the entire system to be compromised. Apache suid()s itself after handling the request, but the Apache user can generally write to a few good places, therefore I use suExec.
Peace sells, but who's buying?
I have found that a truly scaleable design pattern is using a lean little engine like Jetty and a declarative/Rest based architecture. We have recently ported Sugar CRM PHP/Apache to NetKernel and lost over 95% of the code and subsecond response times. We kept the horrible database design and the workflow in the first version as well, so reworking that will further improve performance and further reduce the need for code. For me performance is important but maintainability is equal. The less code the easier to maintain. There is a great white paper from the NK guys here
"If the King's English was good enough for Jesus, it's good enough for me!" -- "Ma" Ferguson, Governor of Texas (circa
"The first order of business is to ensure that atime logging is disabled on file systems. The atime is the last access time of a file, and each time a file is accessed, the underlying file system must record this timestamp. Because atime is rarely used by systems administrators, disabling it frees up some disk time. This is accomplished by adding the noatime option in the fourth column of /etc/fstab."
Can someone share their thoughts about this tweak? Is it safe to use from a data integrity perspective?
I had a customer (I am a contract programmer, working on a per-project basis) who had an emmense PHP / MySQL application that ran so slowly it was unuseable. We did every simple optimization such as is described in this article, and more. In the end, the issue was clearly that there was simply a lot of PHP code, and a lot of it using PHP's objects, and searches through arrays, and that sort of thing. The biggest performance increases we were getting was when we could push some sort of comparison or logic from PHP into the SQL query.
What we did was re-write all of the application except the parts that actually printed HTML to the page in C. We made that library into a php extension, which we added to our php installation. The speed ups varied according to the type of code, of course. MySQL queries changed hardly at all. A simple for loop might speed up from 100 to 1000 times, however, and a for loop that involved some sort of object oriented operations -- say, the creatation of a new object with each iteration, in an extreme example -- could be sped up from 10,000 to 100,000 times.
Now, most code that was sped up 100,000 times, when examined closely, could be sped up in PHP also by writing it smarter. But bad C code still runs faster than good PHP code.
If your disk drives are slow, or your code is printing a debugging log that has every function entry and exit to a network shared disk, or something like that, don't even think about C, just fix the basic problem first.
However, in my experience, twiddling the apache configs for "AllowOverride" and stuff like that will never get you as big a speed up as moving PHP code to C.
Note, that the way we did it, we moved all the core functionality and logic to a C library, but most of the display stuff was left in PHP. This meant that most ongoing development could continue to be done by cheaper, less skilled people who knew only PHP, MySQL, javascript, and CSS.
The reason why Lighty and Litespeed have pulled better numbers than Apache is because they are threaded and use FastCGI, and always get compared to Apache with the prefork MPM using mod_php.
The latest performance numbers show that Apache 2.2 w/ worker MPM (threaded) + FastCGI can keep pace with Lighty and LiteSpeed. Many of us large site maintainers prefer Apache's feature set.
I agree that APC rocks, it outpaces Eaccelerator in a big way, and is more stable.
This article is not worth the read, I could condense it into a 3-fold pamphlet. Performance tuning is an art, this article does it a great bit of injustice.
Some of us make a living doing this and the tools we use on the server have one job.
No, really? I do to too actually.
That job is to send content to the client as fast as possible.
Wrong. That job is to get the job done, fast, good and cheap, and if that doesn't work (which it never does) it's to evaluate the best tradeoffs without bugging the client to much. And by client I mean the one with the two legs and the checkbook that doesn't give a damn wether you're using Ruby or PHP or Django or Symfony or Zope or Rails or whatnot but wants to see his webapp ASAP.
There are numerous tradeoffs in the architecture and configuration of web servers and scripting languages and when you're working with this stuff everyday the sub-optimal becomes irritating.
And you know what the suboptimal and the optimal is? No? Well, then you are aware of more than most posters I sorta quoted above.
If it's all a bit over your head, I suggest you instead participate in discussions at a level you're more comfortable with.
WTF? I've been programming since '86 and have been doing webstuff for a living since 2000. I don't see nothing over my head here. Just a tad incoherent for a community made up of what seems like 90% part-time webdevs with each their own favorite toolset. A community of which 80% act as if they where members of the Linux Kernel Team and come across a bit silly at times. Don't get me wrong, there are interesting posts here. But for each of those it looks as if three 'expert' posts sound like what I was moking. And that what I was poking at with the parent post.
We suffer more in our imagination than in reality. - Seneca
BTW - I noticed that PHP5.2.1 on my home machine (Sempron64, Kubuntu AMD64, 2.0Ghz) to be consistently at least 1.5-2 times faster on (micro)benchmarks than the same PHP version "hand-built" with usual optimizations and the same AFAICT ZTS and other settings on Core2 Dual Xeon machine on RHEL4 i386 (1.8GHz). How comes? Is AMD64 ABI really that great for PHP or what? Python's benchmarks, OTOH, generally don't show any improvement between i386 and AMD64.
The blog site of sina.com(ranked 13 in global traffic by alexa index) is built entirely with PHP. It's the biggest blog site in China, with more 50 million users including thousands of Chinese celebrities. The blog site deeply use ajax techniques and has a video blog built also with PHP. My point is that if PHP can handle an interactive website(AJAX+Video) with more then 50 million users and more than 10 million page hit a day, what else in the 'net' PHP cannot do?
China, in fact, is very fragile.