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."
That sounds like a rather dumb comment. I also bet you are comparing lighty to apache 1.3. Or you do not know what you`re talking about. I have had (until february) a P3-400 w. 256 MB with around 200 Domains configured (of which 2 make up for 98% of traffic)
running a LAMP Stack w. apache 1.3. The machine serves 6 concurrent users with 8.9 Database-Hits/Sec serving around 30-40G/month.
I have absolutely no problem with apaches speed when it comes to serving pages. It does lag when forking processes, though, so I have to keep a certain quantity of processes in reserve (20).
This leads to memory problems, especially since, with mod_php, the process size alway increases but never decreases with apache-process age. Thrading (where basically memory is shared) and Fastcgi for the php should cure that. And that is what lighty does. But: with apache2, worker mpm and mod_fcgid, it works, too.
Then all you need to do is keep keepaliverequests reasonable and keepalivetimeout low. And get a reverse proxy (apache2.2).
Lighty is probably good, but I do not think it has much advantage over a well tuned apache.
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
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.
- Use apc or eaccelerator. (yahoo uses apc so that is the one we went with). This alone will give considerable benefit.
Apc can defaultly cache any of the php that runs or it can also be used as a local cache for objects you'd like to store programmatically.
- If you need distributed items, especially in a non-sticky load balanced environment, look at memcached.
- Use a query cache for your db
- If your db connections are expensive, look at sqlrelay
- Look at whether a caching proxy is a possibility for you (squid or apache has some mods).
- Benchmark your pages and functions. It is the only way to know if configuration tweaks are adding any value. I usually do this after a full profiling using apd (to help identify the bottlenecks and frequently called functions). I usually run apache's ab to get a look at page benchmarks.
- you can always write c extensions for items in php that are too slow. Of course, you'll have to know c, increased maintenance, development time, etc
There are a million things to be done to increase performance. Obviously, don't use anything blindly. Still, I think the opcode cache (apc or eAccelerator) is probably the easiest and most substantial win."I also expect that the language is going to be forked at some point unless the PHP developers clean up the function naming - it's infuriating."
There's nothing to stop you from cleaning up the function naming. We'd all appreciate it :-)
Also, if you really want performance "uber alles", don't bother with apache or any other "pre-made" server - write a custom server in c designed to load modules that serve just the content you want served. You can then handle a thousand requests per second (including time to access the database a half-dozen times per request) on comodity hardware.
Its not like there isn't code out there that shows you how to implement a server in c, how to write and load modules in c, how to use threads in c, and how to access mysql via c. You'll be super fast ... except that your development time will be super slow.
apache+php is a compromose that most people can live with, most of the time.
Yes, the function naming in php is crap. Show us a scripting language where it isn't.
All that apache does when serving PHP requests with mod_php is run the early phases (auth, URL mapping) and pass the request to PHP. Do you really think that Lighttpd + FastCGI is going to be significantly faster than that? The bottleneck is your PHP code, not the web server.
Lighttpd is probably faster at serving static content. Most sites don't have enough bandwidth to find out.
It includes:
Disclaimer: this is stuff that I have written.
2bits.com, Inc: Drupal, WordPress, and LAMP performance tuning.