During our searches for better ways to scale drupal, we stumbled upon Caucho Resin, a Java servlet container that provides a native Java based PHP5 interpreter. Resin can run as a replacement for Apache or lighttpd, or can work in cooperation with an httpd server.
Caucho provides a Java-based PHP interpreter. What does that mean? Well, unlike Apache, which uses an embedded PHP interpreter called mod_php, or LightHTTPD which uses fastcgi, Resin is running as a drop in replacement for the server, so there is no external module. PHP runs as a Java servlet inside of a Resin container, and for the first time seems to deliver consistent, working, multi-threaded PHP (there is experimental support for multithreaded php - read this and this to become instantly knowledgable - bear in mind that "global" and thread and session specific tend to be totally different concepts in Java and PHP, for example there is no way to be "global" in the servlet spec, only global to the servlet instance inside of the application server, so multi-threading gets complicated really quickly. When you run php in Java, how do statics behave for example?).
The interpreter only has to be started once, as opposed to a new interpreter for each request as you would with a web server (either mod_php or fcgi), which provides a shorter round trip, less memory consumption, and in theory, insanely fast performance.
Jonathan and I have been watching for this technology for a long time, and I think we've finally found it!
So, to give you an idea of what kind of performance, Caucho's site claims 4x improvements over standard mod_php with many applications, including Drupal.
So, we decided to use some of the machines in our lab to try this out. Seems like a good idea, no?
Well, I'll be damned if they weren't correct. Here are the results:
Preliminarily, and we would appreciate it if we could get some external verification, it looks like Resin is performing almost 3.5 to 4 times faster for a stock Drupal install than apache with no caching enabled and the same hardware.
We ran our own benchmarks against the following hardware:
We benchmarked three different configurations on the same hardware and against the same database using stock configurations for all software.
The test case consisted of running multiple requests to our test server with the path '?q=node/1' as a logged in user (PHPSESSID cookie set) using Jakarta JMeter. For each of five different concurrent thread counts (1, 2, 5, 10, and 20, respectively), we sampled the total number of requests per second driven by each of the test cases.
The only downside we've seen so far: Configuration of rewrite rules is difficult, which means that clean URLs in Drupal will be problematic. We might need a Drupal bounty for this one.
More information on this is to come. We're definitely going to be doing further investigation, and have already been in touch with the deveopers. We'll be talking more extensively with Caucho and asking them how they did it, why it works, and what kinds of drawbacks we might be looking at.
This looks promising, folks. Stay tuned.