couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <robert.new...@gmail.com>
Subject Re: svn commit: r815404 - /couchdb/branches/0.10.x/etc/couchdb/default.ini.tpl.in
Date Tue, 15 Sep 2009 23:17:21 GMT
A "durability matrix" that lays out all the possible combinations of
headers and behavior would be a good place to start. Something that
clearly states when data is synced to disk (and what fsync does on
different OS'es) would be an excellent deliverable in its own right. I
don't know all the spots on that grid, but perhaps I should start a
wiki page with what we do know?

B.

On Tue, Sep 15, 2009 at 11:54 PM, Jan Lehnardt <jan@apache.org> wrote:
>
> On 15 Sep 2009, at 20:30, Chris Anderson wrote:
>
>> On Tue, Sep 15, 2009 at 10:22 AM, Jan Lehnardt <jan@apache.org> wrote:
>>>
>>> On 15 Sep 2009, at 19:09, jchris@apache.org wrote:
>>>
>>>> Author: jchris
>>>> Date: Tue Sep 15 17:09:22 2009
>>>> New Revision: 815404
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=815404&view=rev
>>>> Log:
>>>> changed default for 0.10 to delayed_commits = true for fast out of box
>>>> experience
>>>
>>> Chris, please discuss this first on dev@.
>>>
>>
>> Sorry about that - just having a strong gut reaction to the potential
>> of releasing 0.10 that's too slow to use.
>>
>> Good thing is that this commit got everyone talking on IRC.
>>
>> The basic tradeoff here is between safety and speed. With a simple
>> benchmark on my Mac laptop (OSX 10.5) delayed_commits gives ~230
>> writes/second while we only get about 5/sec with the slow safe option.
>>
>> I think 5 writes/second is too slow to be useful, so it doesn't matter
>> how safe it is.
>
> I think we need to define use-cases a bit more clearly and then try to
> determine how much safety we can and want to guarantee. I'd like to
> avoid situations where we send a Created 201 response when that
> doc is still in limbo and CouchDB could do extra work to make sure
> it is on disk.
>
> I especially don't want to enable delayed commits by default for simple
> speed-freak reasons. CouchDB could easily detect long running fsync()s
> and send a log entry about enabling delayed commits. Proper documentation
> & release notes will help too. Finally, there will always be people claiming
> CouchDB has whatever properties (slow, fast, green) they see fit*.
>
> If we want to bill CouchDB as everybody's personal database, we better
> keep that personal data safe :)
>
> Cheers
> Jan
> --
> * See Postgres.
>
>
>
>
>
>

Mime
View raw message