Even if there’s no expensive request, the clusters eventually stops responding after 1 day.

http://headius.blogspot.com/2007/04/paving-road-to-jruby-10-performance.html

We perform well serving up Rails requests today, but only about 50-70% of Ruby 1.8’s performance.

Not quite there yet, but maybe something to hope for in the future.

If you want to use embedded PHP code in your Web pages, you need to build it in one of two different ways, depending upon whether you want to load it dynamically or have it built permanently right into the Apache server. The only difference between the interpreter and dyanmic module builds is the configure command; the sequence for building it as a static module is considerably more complex.

We perform well serving up Rails requests today, but only about 50-70% of Ruby 1.8’s performance.

Not quite there yet, but maybe something to hope for in the future.

Mongrel: C, eh? Surprised to hear that. I was beginning to think it was written in PPC-native RealBasic, running under emulation of course. Regardless, the name mongrel is ironic, because it really is a fucking dog. I love how it stops responding if idle for more than a couple of hours!

PHP & mod_php: Hm. You’re shaking my preconceptions to the core here! Here’s what I had believed:

I thought that mod_php basically encapsulates instances of PHP, as you say, in Apache memory space. Kind of like little PHP VMs. But I did think that mod_php parsed the page first, as I thought that would be faster, and it is Apache reading the page. The PHP instance would be loaded from /usr/bin – that’s the one with MySQL linked into it, remember. The actual internals of it I have no idea about. Anyway, I’m sure you’re right and I’m wrong – I just kind of assumed that’s how it worked!

The whole of JRuby is the most ridiculous thing I ever heard. If you’re going to be compiling it down, you may as well compile it properly and run it as object code! Why go to another intermediatory language’s bytecode, which then needs to be run in yet another VM? And what does that mean for testing? What about Ruby plugins? Which DB adapter is used? Etc, etc. I have a lot of doubts about that “solution”. And one wonders what the point of using Rails at all will be. If you want to use Java, use Java, you could certainly do a lot worse.

And it’s Ruby 1.9 that will apparently introduce the new VM, with a java-style JIT compiler. However, I have very low expectations that will be released anytime soon. It’s been in development over 2 1/2 years now, and is supposedly due this December .. if so, shouldn’t it be in RC’s by now? But I don’t hear any reports that it’s anything like stable. I am actually kind of worried that Ruby is a bit .. ponderous in its development.

Even so, testing I’ve seen suggests a speedup of between 30-100% on average. While welcome, it’s nowhere near enough. It needs to be 10 times faster, not 2.

While many people will argue that Rails can be tweaked to perform better, there’s only so far you can go before you’ve “tweaked” away so much of the development niceties that you may as well have not used it in the first place.

Minor factual points:

- Mongrel may be written in Ruby but the performance-critical parts are written in C, and algorithmically speaking this is lightning-fast C at that (because they are largely an ultra-efficient DFA, or Deterministic Finite Automata, generated by Ragel).

- Your discussion of PHP makes it sound like it’s just a command-line executable (in the same way that Ruby is) and although this is true, almost all use of PHP in the wild is actually done via an Apache module; I am no expert on Apache’s dispatch mechanism but my primitive understand of it is that once loaded the module resides in and shares Apache’s memory space so there’s no expensive fork/exec operation for each request nor is there any complicated or slow Inter-Process Communication.

- You make it sound like Apache parses the requested files looking for PHP code blocks and only calls out to the PHP interpreter on hitting them; my understanding is that when it sees the file extension on the request it just passes the whole darn thing on to PHP and Apache doesn’t do any parsing at all (the PHP interpreter then interpolates the PHP output with the non-PHP parts of the source).

As for the finer details of Apache’s dispatch mechanism for Rails and PHP, can’t really comment. But by and large I agree with everything you said.

There seems to be a lot of hope that JRuby will be a solution, but anything which involves compiled down to Java bytecode doesn’t seem much of a solution to me, given that Java has its own deployment nightmares as well.

Ruby 2.0 looks promising, but we’re still only talking about a modest speedup, and Ruby is only one of the links in the chain. I really don’t know what the answer is.