Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of mikeal.rogers@gmail.com
 designates 209.85.214.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=M3HvssuBSGFnoJTjVYhsHhpPBjAvXV9+QKAQ5UZPKykD7ZuAyxayglspKuzYtUwSHm
         3uTDZok+DcsWp1PaoYQKoKHTfbRf35ci0JV0WbcCFpWTDaU0wadV3ktFU5PRocjpykCT
         k/zmfRm4011v9zQBy0HXqvJeYJix8AFHZ01Gg=
MIME-Version: 1.0
In-Reply-To: <4C33B24E.8050109@gmail.com>
References: <4C31FF1A.30002@gmail.com>
	<FDFF9131-A857-48C1-A2E1-5DBD39323F66@apache.org>
	<4C33B24E.8050109@gmail.com>
Date: Tue, 6 Jul 2010 15:52:12 -0700
Message-ID: <AANLkTinrVjvfQuBwsk30vOoj2L0W2V0zOZDM82Ss4hke@mail.gmail.com>
Subject: Re: delayed_commits false
From: Mikeal Rogers <mikeal.rogers@gmail.com>
To: dev@couchdb.apache.org
Cc: Damien Katz <damien@apache.org>
Content-Type: multipart/alternative; boundary=001636e1eed5667e95048abfe7f4

--001636e1eed5667e95048abfe7f4
Content-Type: text/plain; charset=ISO-8859-1

I think there is a balance that we can find here between user experience and
durability.

I think the biggest question for me is, who is the primary target of the
tarball download?

If it's developers, I think we should leave it on.

If it's people who are going to put it up, vanilla, in to production, we
should turn them off.

I know that I would certainly advocate keeping them off in the CouchDBX
build.

-Mikeal

On Tue, Jul 6, 2010 at 3:46 PM, Volker Mische <volker.mische@gmail.com>wrote:

> On 07.07.2010 00:06, Damien Katz wrote:
>
>>
>> On Jul 5, 2010, at 8:49 AM, Volker Mische wrote:
>>
>>  Hi All,
>>>
>>> delayed_commits were enabled to have better performance especially for
>>> single writers. The price you pay for is that you potentially lose up to one
>>> second of writes in case of a crash.
>>>
>>> Such a setting makes sense, though in my opinion it shouldn't be enabled
>>> by default. I expect* that people running into performance issues at least
>>> take a look at the README or a FAQ section somewhere. There the
>>> delayed_commit setting could be pointed out.
>>>
>>> I'd like to be able to say that on a vanilla CouchDB it's hard to lose
>>> data, but I can't atm. I'm also well aware that there will be plenty of
>>> performance tests when 1.0 is released and people will complain (if
>>> delayed_commits would be set to false by default) that it is horrible slow.
>>> Though safety of the data is more important for me.
>>>
>>> If the only reason why delayed_commits is true by default are the
>>> performance tests of some noobs, I really don't think it's a price worth
>>> paying.
>>>
>>> *I know that in reality people don't
>>>
>>> I would like to see delayed_commits=false for 1.0
>>>
>>
>> Last year we turned off delayed commits by default. We got lots of
>> complaints, the performance impact was too great. So we switched it back. We
>> aren't the first storage engine to go around on this. For example, Apple's
>> core data switched to using full fsyncs for each write in 10.4, but then
>> switched it back for 10.5:
>>
>>
>> http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreData/Articles/cdPersistentStores.html
>>
>> "Important: The default behaviors in Mac OS X v10.4 an 10.5 are different.
>> In Mac OS X v10.4, SQLite uses FULL_FSYNC by default; in Mac OS X v10.5 it
>> does not."
>>
>> Anyway, we can improve the documentation warning's, etc, but we should
>> stay with the current defaults.
>>
>> -Damien
>>
>>
> As 1.0 is approaching fast, I think this discussion is pretty important.
> Especially this thread showed that there are people that prefer setting
> delayed_commits to false. Although sometimes someone has to make the last
> call, and there is probably no one better than the creator of the project, I
> think it this case the decision should be made by more people.
>
> For *me personally* the authority of Apache CouchDB are the committers. I
> would love to see them vote on this topic (being it public or private
> doesn't matter).
>
> Cheers,
>  Volker
>

--001636e1eed5667e95048abfe7f4--