Drupal module performance
Now that chx has beaten me to it, I'm going to profile and patch and find all the low hanging fruit to cache in drupal. Here's an improvement to the module_hook function.
drupal theme performance
I've been playing with callgrind, xdebug, and kcachegrind to profile drupal. I'll go over the details of my results in a future blog entry, but if you want the short story just check out Rasmus's directions. Rasmus has given lots of talks with similar names to "Getting Rich with PHP5" and I'll leave it to the reader to google and find slides from this talk.
Profiling is an iterative process, and after awhile I might blog about it with something more concrete. But for now, I have early results.
Running multiple webservers on a single port (sortof)
Play with any webserver long enough, and you'll realize, they aren't all the same.
On one end, you have light webservers that respond to requests for static content off of a disk, and then send it to the user. thttpd is an extreme example of a webserver like this. Others instead will use apache with hardly any modules installed and, if apache 2.x, a worker MPM can be used that enables each process to serve multiple requests.
Well, that's all fine and dandy, but if you're using PHP or some other language you might find that your web applications aren't thread-safe. Suddenly you have concurrency issues, because you'll have two PHP interpreters running inside of the same process, and this can create enough issues where php recommends against it.
So you equip your apache with mod_php and off you go - but now each request for a small static file bogs down a massive apache process. Which is a bummer, because thttpd or even apache could serve the request with far fewer resources.
Template Engine Performance Bake-off
PHP was started as a template engine but it's grown into a full featured language, so much so that for some, keeping logic and presentation separate is a real challenge. That's led to an entire class of "template engines" being implemented on PHP. On one extreme, these engines provide a wholly distinct template markup language that in turn is compiled into PHP - e.g. Smarty. On the other side are contenders like Savant - but the unanswered question is, how do they perform?
http_load hack
I'm working on a blog entry comparing the performance of different templating engines (Smarty, Savant, etc.) and one thing I wanted to do was use http_load to provide data points regarding performance. Trouble is, while http_load kindly provides connection times and first response times means, minimums, and maximums, it doesn't provide a standard deviation. Given that my test environment is a multi-user operating system and other things are running, I am a bit concerned that measurements might contain extra variation because of background processing time.
While not a perfect solution, a good start is getting the standard deviation of measurements. Now, I can compare means with more confidence (ha, ha, a statistics pun) in determining what makes a difference. So, this hack is adding standard deviations to http_load output.
A tiki performance shakedown
A few weeks ago, I was brought in to help raise the performance of a site running tiki that was under high load.
I saw Rasmus Lerdorf give a very interesting talk on PHP optimization called "Getting Rich with PHP5." In it, he recommends the use of valgrind as a way of holistically profiling a web server running an application. That's a nice way of seeing what's holding you down when you have that luxury, but what can you do when the machine is under heavy load?