Optimize PHP and Accelerate Apache 191
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? (Score:3, Interesting)
Dump Apache! its the slowest link!
use Lighttpd [lighttpd.net] + latest PHP 5.2.2 + APC [php.net]
Re:want performance from php? (Score:4, Interesting)
Re:want performance from php? (Score:3, Interesting)
TFA reads like a newbies blog article, 'OMG I know how to haX0r php.ini and httpd.conf'. Any half decent sys admin already knows all this - it's obvious and well documented stuff. I wouldn't be surprised if the author just reworded a couple of blog entries for this article.
Modules (Score:2, Interesting)
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.
Dunmp then both (Score:2, Interesting)
Re:want performance from php? (Score:3, Interesting)
So far Apache is good enough for me, but if you're going to replace Apache with something that is fast and has features, you may wish try Zeus.
Anyway, I'd dump PHP first. PHP is slow and has tons of security problems - and judging from the way the devs do stuff, there'll be plenty more to come.
In the previous article (Score:1, Interesting)
"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?
C code is one answer (Score:3, Interesting)
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.
Its all about how you use Apache (Score:2, Interesting)
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.
Re:want performance from php? (Score:5, Interesting)
Re:want performance from php? (Score:3, Interesting)
Re:Just listen to this (Score:4, Interesting)
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.
PHP rocks on AMD64? (Score:3, Interesting)
PHP is still the hottest. (Score:2, Interesting)
Re:want performance from php? (Score:4, Interesting)