On Aug 15, 2009, at 11:43 AM, Chris Anderson wrote:
On Fri, Aug 14, 2009 at 6:55 PM, <[email protected]> wrote:
Author: kocolosk
Date: Sat Aug 15 01:55:32 2009
New Revision: 804427
URL: http://svn.apache.org/viewvc?rev=804427&view=rev
Log:
delayed commits are now a config option, off by default. Closes
COUCHDB-449
I understand the value of this, but I'm not sure about whether it's
the best way to greet new users. In informal benchmarks just now,
delayed_commits makes CouchDB more than twice as fast. With
delayed_commits=true, hovercraft:lightning() does 100k docs in just
under 10 seconds. With the new default, it takes roughly 25 seconds.
And of course the problem will be much worse for anyone doing user-
friendly PUTs instead of _bulk_docs.
We had this discussion once before, and came down on the side of speed
- what made us change our mind?
In fact I don't know that we ever really did discuss what the default
ought to be. When Damien added the feature he said [1]
Right now the default is to delay the commits, because I think that
will be the most common use case but I'm really not sure. I
definitely want the commits delayed for the test suite, to keep
things running fast.
but the rest of the thread dealt with the precise guarantees of the
fsync() and fcntl(F_FULLFSYNC) calls. No one talked about the default,
but in COUCHDB-449 all votes were for safety first.
I believe we should try really hard not to lose users' data. With
delayed_commits = true our durability story is basically the same as
Redis'. I think that would be surprising to most new users. Best,
Adam
[1]:
http://mail-archives.apache.org/mod_mbox/couchdb-dev/200901.mbox/%[email protected]%3e
