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."

Comments

want performance from php?

[wwmedia]

want performance from php?

Dump Apache! its the slowest link!

use Lighttpd + latest PHP 5.2.2 + APC

Re:want performance from php?

[Ant P.]

I'll second that - Apache is as bad as Firefox when it comes to resource waste. On my machine, lighttpd uses about 1MB of RAM, not counting the PHP processes.

Re:want performance from php?

[Anonymous Coward]

There are many reasons Apache httpd is the standard and speed isn't one of them but lighttpd is pretty awful although lua integration is cool (much faster than PHP). I might say that if you want performance, avoid crap like PHP and Ruby. That's pretty much true but ignores the fact the bottleneck is usually going to be the database, regardless of whatever other software you happen to be running.

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.

Re:want performance from php?

[consumer]

If you use separate processes for your static content and your PHP (either Apache with FastCGI or a reverse proxy), you won't have problems with memory. The size of an Apache process that's just serving static stuff is tiny. It's the PHP processes that take the RAM, and they will do the same when run from Lighttpd.

Re:want performance from php?

[Khazunga]

Lighttpd is awful for any serious use. Until it has a decent URL rewriting module, it's a toy. Apache with an event MPM is on par with lighttpd on speed and memory usage -- ie. it's a bit larger than lighty, but does contain more features.

C code is one answer

[Anonymous Coward]

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.

Re:Just listen to this

[Qbertino]

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.