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 volker.mische@gmail.com
 designates 209.85.161.52 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject
         :references:in-reply-to:content-type:content-transfer-encoding;
        b=eLv0xa8a+BE+VnvS5+CHgKzcXmqkz2YehGuygoz/zpuTLLNbO1W6f3fZLaLSgFHMAG
         iY/7QXeJRcS/rR74fphJoMnsJYpHvW6hGuDsBbA4jR6Rccmu1dI8Hdq9wM/PAuIJOmhm
         K04eoNjxQFb1w2sWz5LfbBE5nr8vyLyzuErkw=
Message-ID: <4C33B5DC.40301@gmail.com>
Date: Wed, 07 Jul 2010 01:01:48 +0200
From: Volker Mische <volker.mische@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: dev@couchdb.apache.org
CC: Mikeal Rogers <mikeal.rogers@gmail.com>,
 Damien Katz <damien@apache.org>
Subject: Re: delayed_commits false
References: <4C31FF1A.30002@gmail.com>
	<FDFF9131-A857-48C1-A2E1-5DBD39323F66@apache.org>
	<4C33B24E.8050109@gmail.com>
 <AANLkTinrVjvfQuBwsk30vOoj2L0W2V0zOZDM82Ss4hke@mail.gmail.com>
 <4C33B509.5070403@gmail.com>
In-Reply-To: <4C33B509.5070403@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

(memo to myself, don't send mails late at night)

On the other hand, do developers care about performance? And if, they 
would read the documentation.

Cheers,
   Volker

On 07.07.2010 00:58, Volker Mische wrote:
> I have to admit that the point, that the main audience of a tarball are
> developers is a good one. Perhaps people that do binary distributions of
> CouchDB (like all the linux distros) could be encouraged to turn it to
> false (though I have no idea what their general policy about changing
> defaults is).
>
> Cheers,
> Volker
>
> On 07.07.2010 00:52, Mikeal Rogers wrote:
>> 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
>>>
>>
>