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
You should compile it yourself wicked fast compiler optimizations on top of your wicked fast install of Gentoo (which you also compiled yourself)
Sucks
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?
no text
My turnips listen for the soft cry of your love
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
Maybe I'm being a cynical bastard again, but that article is REEEALLY light on content. Compared to the other featured articles from IBM, which are usually very rich and informative, this one is more like an "idiots guide to apache", the kind that belongs on Digg's mountain of filth. This is little more than a rehash of the Readme files for Apache and PHP combined. It's about as deep as telling a windows user how to make their PC faster by changing to the Windows NT theme. Of much greater value to web professionals is this article from a fellow OSDN site (!) Lighttpd can lighten Apache's load
-Billco, Fnarg.com
Last year, we dumped apache (and http altogether) and went with a gopherd/fastcgi approach for serving up our php pages. For people still stuck on port 80, we have a squid proxy which converts the request to gopher. Since then, traffic has increased 34%, while average load has dropped by 20%.
Do you even lift?
These aren't the 'roids you're looking for.
Unless these recommendations can implemented in shared hosting environments they are of no real use to someone like me - ie web application designer. In regards to opcode caching I would go with Ioncube as there are runtimes available for most server environments.
[troll]Use Perl, mod_perl, profile your applications, and cache, cache, cache.[/troll]
try LOL - Linux/OCaml/Lighttpd
Do you even lift?
These aren't the 'roids you're looking for.
"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?
Read this instead
It's common knowledge that Apache certainly isn't the fastest out there to server web pages. For static pages lighttpd and, heck, even a basic stand-alone Tomcat (yup, a Java server!) can easily serve as many pages as Apache. That was already the case for, say, Java 1.5 / Tomcat 5.5. Now take Java 1.6 and Tomcat 6 (or, better, Resin [not completely free]) and suddenly Apache is looking even more ridiculous.
For anything SSL related IIS makes fun of Apache.
For many concurrent sessions there are proof of concept servers written in functional languages (like erlang) that handle an order of magnitude (!) more simultaneous sessions than what Apache does.
I understand that for many here Apache is all they know and hence regard it as the holy grail but it is far, far, from being that. It is a good overall purpose web server but it is certainly not the fastest.
In the face of the countless security holes that are all too common in C-written apps I'm now more and more installing pure Java web servers. At first I was using Apache + Tomcat now I'm more and more using Tomcat in standalone mode. Easier configuration, no buffer overflows to patch.
It could be worse. I don't know if IIS runs under Wine, but if it did that would be LIMP.
I routinely experience Apache crashes while using eAccelerator, APC or Zend Optimizer, even with the latest stable PHP. If you use one of these products, be sure to also run some kind of watchdog that will restart httpd if (when) the stack crashes. They're totally worth running in any case. Zend Optimizer speeds up my Drupal installation by a huge amount because of the time saved parsing code.
You also should of course make sure you've got caching happening at every level of your app. Memcached is a great application level cache. Apache side, make sure you enable and configure the memory cache for static files. (mod_mem_cache) and possibly the file cache (mod_disk_cache). Client side, make sure you're caching static files like images, js, css. Apache's mod_expires gives you good control over this in Apache config.
Of course, all of this could be just spinning your wheels if you have badly optimized sql queries or bad table design to start with. Set mysql's slow query log threshold very low to catch these issues early.
std::disclaimer<std::legalese> sig=new std::disclaimer; sig->dump(); delete sig;
Is there an easy way to figure out where my bottlenecks are? We have a LAMP site that used to run fast, but with a new version of CentOS, it now runs real slow and I'm not sure why...
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.
At my company we have our own C++ modules (no PHP layer) which we use to server our content.. though development takes more time we get solid performance...
just get a bunch of old computers, cluster them, and every time the server load gets larger, add another old computer from the junkyard. Parallel computing at its finest.
It includes:
Disclaimer: this is stuff that I have written.
2bits.com, Inc: Drupal, WordPress, and LAMP performance tuning.
At a recent Web conference a guy name Steve told me the best web server to use was IIS from some company called Micro something or other. He was grasping his chair very intimidatingly, so I took his word for it. He also managed to talk me into buying a corporate license for some product called Office something or other. He was a great salesman I must say, since I don't even work for a company!
Kickass Cheap Web Hosting
Some of us make a living doing this and the tools we use on the server have one job. That job is to send content to the client as fast as possible. 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.
If it's all a bit over your head, I suggest you instead participate in discussions at a level you're more comfortable with.
HTH
Could you get more content? This one is pretty outdated, you used to take less time to update...
Copyright infringement is "piracy" in the same way DRM is "consumer rape"
Hey, I'm interested ^^
Besides that white paper do you have more info about it ?
We are Turing O-Machines. The Oracle is out there.
Just keep IIS in its native environment and we'll get WIMP... :)
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
Blah, blah, Ruby, django, ASP, ASAP, blah, blah, programming 86, blah, 90% part time weddevs, blah, blah, YHBT, HAND.
Here are a few tips:
Best of luck!
Lighttpd (or any of the good event driven webservers, lighttpd is awful) can't solve this problem. If your database is running slow, the requests that "start to queue up" are requests for PHP scripts. Static files will still get served just fine. Lighttpd has to have just as many concurrent PHP processes as apache does worker processes or threads. Either way its the same problem, lots of PHP processes/threads hanging around sucking up lots of RAM.
If you're running WordPress, then it's even more critical, and you've got tons of options.
Rudd-O - http://rudd-o.com/
Django.
Rudd-O - http://rudd-o.com/
...for most many cases, is to setup an edge server / reverse proxy. It will stop the load BEFORE it even reaches lighty / apache / whatever.
:-)
It's very easy to do, take very little time, reliable & proven (which is not always the case with php accelerators), and will easily drop a double-digit server load to a single one.
It constantly amazes me how people will do the hardest stuff which gave the minimum return first.
Such is life I guess
If you want more proof, read this guy's article. He sell a "turbo charged" Wordpress, got digged and overloaded, optimized his website and still overloaded. Finally his server managed to go through it after he implemented squid's reverse proxy.
In summary - sort out your priorities guys.
Biggest back for the buck first, and then go down from there.
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.
you don't wanna mess up with millions of (awesome)PHPers, or they gonna eat you alive...
China, in fact, is very fragile.
it's "Claris"
my password really is 'stinkypants'
"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."
Kinda young aren't ya sonny.