These numbers look pretty bad… or good, depending on where you stand, I guess. I find it hard to believe that Rails is that much slower than Quixote/Durus for a truly similar task but hey I'm on the right side of this one so I won’t complain too loudly.
Mike, you've given some info about the tests but it would be really
helpful if you provided everything needed to recreate them. Specifically,
the versions of Rails/Instiki/Quixote/MoinMoin and the specific URI stems
you were pointing to with ab. Otherwise stuff like this can be taken the
wrong way and turn into a big Python-vs-Ruby flame-fest. If your numbers are
correct, I can’t see the test setup making a whole lot of difference but
still…
There are lies, damn lies, and statistics, unless you provide absolutely everything needed to recreate the statistics, in which case there are only lies and damn lies. We can reduce this a little further by removing the speculative concept of damnation, leaving us with just lies. This is probably the best we can do without killing everyone, which I'm not sure we can accomplish in any predictable time-frame.
LATER: Mike takes a closer look at his tests, revealing some issues with the comparison method.
Anyway…
I also wanted to comment on some of the RDBMS vs. Durus/ZODB stuff as I've been down this road myself and have been meaning to write about it a bit.
Mike compares relational persistence and object persistence:
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.
Object databases like Durus/ZODB and relational databases are apples and
oranges (or possibly oranges and mangos). I've recently been down the
let’s put everything in ZODB
path and it comes with some problems:
ZODB/Durus using FileStorage can only be accessed by a single-process.
ZODB/ZEO or Durus/ClientStorage can be accessed with multiple processes over a network much like most relational databases but there is no concept of “multiple databases”. If you want multiple databases, you need multiple ZEO servers running.
LATER: Richard Jones corrects me on this and also the packing thing below.
Durus has issues with multi-threaded access.
There’s not a lot of cheap hosting options that have ZODB/ZEO running out of the box or that will let you run any number of long-life processes.
ZODB maintenance (packing) is a pain in the ass, IMO.
Indexing is hard. The BTree classes get the job done but handling multiple indexes on objects can be tedious as you have to keep multiple BTrees in sync manually. (No I'm not talking about the full text index catalog crap. I need fast lookups on specific attribute values).
Only Python code can access the database. I shrugged this off at first but found that it’s actually really2 nice to have data in some kind of language-independent storage.
There are a whole range of situations for which these issues aren’t really issues at all and relational persistence has its own set of issues. But in my experience, making the decision between ZODB and relational has been less about what’s better for the code and more about what’s better for the data. That being said, I use ZODB quite a bit where I used to throw up hacks around pickles and shelves and also when I know I will have complete control over the application environment and don’t have to play nice with others.
Leave a comment