Rails vs Quixote

I have no intent to dial deep into the Rails vs The Rest of the World discussion which seems to be spreading out through various static and dynamic programming language communities.

But as it happens I needed to implement a simple Wiki component for a web app project I’m working on, and as it happens I’ve been stealing looks at Instiki on Ruby/Rails as well as MoinMoin and all the rest, trying to decide upon a bare bones set of features I wanted to build in at this stage. Suddenly, Apache bench ab appeared out of nowhere… and the results are interesting:

(Update: Do also check out Ryan’s Questions before coming to conclusions)

Quixote based Wiki / Apache-SCGI:
(two _q_lookups deep /wikis/awiki/apage )
Document Length:        8596 bytes 
Concurrency Level:      4
Time taken for tests:   2.159 seconds
Complete requests:      500
Failed requests:        0
Broken pipe errors:     0
Total transferred:      4401159 bytes
HTML transferred:       4301961 bytes
Requests per second:    231.59 [#/sec] (mean)
Time per request:       17.27 [ms] (mean)
Time per request:       4.32 [ms] (mean, across all concurrent requests)
Transfer rate:          2038.52 [Kbytes/sec] received


Ruby on Rails based Instiki / Ruby WEBrick/1.3.1 HTTP Server
(a simple wiki page)
Document Length:        8572 bytes ( a few bytes shorter, a simpler path )
Concurrency Level:      4
Time taken for tests:   29.245 seconds
Complete requests:      500
Failed requests:        0
Broken pipe errors:     0
Total transferred:      4400000 bytes
HTML transferred:       4286000 bytes
Requests per second:    17.10 [#/sec] (mean)
Time per request:       233.96 [ms] (mean)
Time per request:       58.49 [ms] (mean, across all concurrent requests)
Transfer rate:          150.45 [Kbytes/sec] received

Result: Quixote’s Windmills churn faster then Rail’s Train, turning in 262 vs 17 requests per second on my workstation, 2.16 seconds to complete the task vs 29 seconds. And Windmills don’t pollute! ;-)

Am I missing something? The Python / Quixote application using Durus as back end storage, driven with SCGI fronted by Apache blows the pants of Ruby and Rails, for an application of similar if not a little more complexity. Admittedly the setup is just a tad more complicated than the all-Ruby download and run Instiki, but we can fix that and do a more apples to apples comparison:

Here’s that same Quixote application being driven by a basic python-only web server, no doubt comparable to Ruby’s WEBrick server. Basing a driver off of “simple_server.py”, completely cutting SCGI and Apache out of the picture:

Quixote based wiki / Python HTTP Server
Document Length:        8596 bytes
Concurrency Level:      4
Time taken for tests:   2.070 seconds
Complete requests:      500
Failed requests:        0
Broken pipe errors:     0
Total transferred:      4401000 bytes
HTML transferred:       4298000 bytes
Requests per second:    241.55 [#/sec] (mean)
Time per request:       16.56 [ms] (mean)
Time per request:       4.14 [ms] (mean, across all concurrent requests)
Transfer rate:          2126.09 [Kbytes/sec] received

Hey! An increase in throughput for the pure python solution, and I think this is a fair enough raw performance comparison between the two application frameworks.

I don’t intend to spend the time required to fully compare Rails and Quixote on a design or functional level. Near as I can tell Rails tries to be a “plumbing” framework, designed to make a web application developer’s life easier. Quixote is that, too. Unless someone with knowledge of both environments can illustrate otherwise, I’ll assume that both have comparable goals and comparable levels of complexity and capability.

Rails has a SQL object relational mapper; Quixote imposes no such thing but doesn’t get in your way of using SQLObject, ORM, Cucumber, any other o-r mapper, or no o-r mapper at all. I’ve done all of the above, but am slowly retiring all my SQL based code (where sensible) in favor of Durus, a ZODB inspired object database. Quixote sister project “Durus” provides an easy to use object database which is far more productive than force fitting objects to SQL. Durus certainly not limited to writing web apps.

Rails has an ASP-like templating language, the Quixote folks eschewed yet-another-templating-language in their design and picked what was natural to them, a way to make it easy to output – safely (!) – escaped or raw HTML from within Python callables rather than force fit a python-like language within (x)html. But again you have a choice – and it seems that many are using templating languages such as TAL, Cheetah, and others with Quixote.

What’s appealing about Rails is no doubt the cohesiveness of the overall package; my feeling is you get the same with Quixote, Dulcinea and Durus – a nice tight package and a bunch of pre-written components to give you a head start to boot.

Noted on Jeffrey Shell’s blog yesterday:

I’m not blown away with Rails. I’m personally more interested in tool kits like Seaside and Wee. Many other pieces of Rails I’ve seen done in Bobo / Zope to varying degrees. I still believe that Bobo, aka the “Python Object Publisher” is a significant piece of web technology and is still a fundamental part of Zope 2 and 3, wherein an HTTP (or FTP, or other) request is translated into an object call. The Python Object Publisher is an ORB [Object Request Broker] in this sense. Beautifully simple and powerful.

Quixote (white paper) takes this one simple idea from Zope, and keeps it simple while also providing web developers with a highly productive environment to build applications with, and as a (perhaps intended?) bonus, simplicity allows Quixote apps to enjoy high performance without a lot of architectural gymnastics.

Quixote, Dulcinea, Durus and other goodies available here.