couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Volker Mische <>
Subject Re: delayed_commits false
Date Tue, 06 Jul 2010 23:01:48 GMT
(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.


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<>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:
>>>> "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

View raw message