As we get ready to release Jaxer 1.0, we put together a few simple benchmarks to see how it performs relative to a couple of other web platforms: PHP and Rails. We wanted to answer a simple question: how does Jaxer, with its server-side DOM and JavaScript, perform relative to these other popular alternatives?

This was not designed to be an all-encompassing shoot-out, or a detailed study of everything you might want to do in a web app. Instead, we took a few common tasks — making database requests, using JSON, etc. — and implemented them as you might expect in the three platforms. We made enough DB requests and JSON calls and so on to give us a reasonable number of milliseconds to measure. But we also wanted to make the repetitions representative of what you might find on somewhat intensive real-world page, so we're not making a million DB requests, just a hundred, for instance. And we included one benchmark of serving an almost-static page: the "almost" was to make sure we were measuring the time the platform took to really read through the page, in case it had dynamic content in it. (Otherwise, if the page were truly static, you could always arrange for the web server to serve it without involving the platform.)

The first chart shows how long each platform took to perform the task. For the "static" page, we measured the total time taken to serve the request, as measured by the external web client making the request (over the local network). For the other benchmarks, we measured the time taken to perform the specific task itself, excluding the overhead of setting up and tearing down the benchmark, serving the test page, etc. That allowed us to combine these tests and assess what an entire page would take to serve, if it had static content and database requests and some JSON manipulation and so on. Of course your mileage may vary: your app may have less DB requests, more JSON, less IO, whatever. But remember the question we're trying to answer: how does Jaxer perform relative to other accepted platforms for several common tasks? We believe these benchmarks answer that: Jaxer performance is very much comparable to PHP and Rails.

Of course, significant boosts to JavaScript performance are around the corner for Firefox (see Brendan's TraceMonkey article). Since Jaxer is built on the same engine as Firefox, those same improvements will soon be in Jaxer too... With the imminent and massive improvements to JavaScript performance coming to the Mozilla engine.

Now let's take a closer look at these tests below. All were run multiple times on a Macbook Pro (2.5 GHz Intel Core 2 Duo) with 4 GB of RAM.

The "Static" Page

We grabbed a copy of one of our blog pages (Aptana Acquires Pydev) and saved it locally. We turned it into a .php file with a smidgen of PHP in it; we threw in a short <script runat="server">...<script> for Jaxer; and created a simple view out of it for Rails. Jaxer was the slowest to serve this page, and not surprisingly: it needs to parse and create the entire DOM of the page to allow server-side manipulation. Still, under 20 ms is pretty good, and is usually dwarfed by weightier tasks such as DB queries.

Loops

To measure raw iteration speed we created some very simple loops with and without a bit of variable manipulation. This time Jaxer was far faster than PHP or Rails: at least for simple, common for loops, Mozilla's SpiderMonkey JavaScript engine is no slouch.

JSON

Using JavaScript literals as a serialization format predates Ajax, and has become an incredibly prevalent cross-platform data format. We created a simple JSON structure and a more complex one, and measured a variety of encoding and decoding tasks. All three platforms now have native JSON support, so all three performed very well in this benchmark.

IO

To measure typical file I/O performance, we created a 1 KB string and wrote it to a file, then appended a 100 KB string, and read the whole thing back, and repeated it a few times. Jaxer came out somewhat slower than the other platforms: some of this may be due to the extra conversions between JavaScript's native utf8 encoding and the filesystem, but we'll need to go back and dig deeper.

DB

To measure database performance, we tried to level the playing field as much as possible by coding straight SQL statements. We also emphasized SELECTs over DML queries because most apps read much more than they write. Jaxer came out somewhere between PHP and Rails, with half its time spent wrapping the raw MySQL data in easier-to-manipulate JavaScript structures. Of course in real-world apps you're likely to use prepared statements, and very often (esp. in Rails, and soon in Jaxer too) an Object-Relational Mapping such as ActiveRecord to abstract out the SQL calls.

Scrape

Finally, we included some page scraping tests. Many web apps mash up other content, repurpose it, or extract data from remote sources. In our case we read in the same blog page as in the static example, and navigated it in a variety of ways. PHP was fastest here, with Jaxer slightly behind and Rails a distant third. Looking for a moment beyond performance, Jaxer is the only platform that would allow scraping of true Ajax web pages, for example pages that created their content "client-side" via Ajax calls.

Try it yourself

You can download the complete source we used to generate and display these results, and try them yourself. The README file should have the instructions you need. You can grab Apache+Jaxer from the Aptana download site, Apache+PHP+MySQL from several places such as XAMPP, and Ruby and Rails from RubyOnRails.org (if it isn't already on your platform — you'll need Rails 2.1.0, the json Ruby gem, and to run the tests in production mode).

Feedback

If you'd like to discuss these, I've started a forum thread for this.