couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikeal Rogers <mikeal.rog...@gmail.com>
Subject Re: delayed_commits false
Date Tue, 06 Jul 2010 23:04:03 GMT
The difference when you do a couchapp push with delayed-commits on and off
drastically increases when you have a lot of binary attachments.

In some of my apps it's the difference between sub-second and 20 seconds.

-Mikeal

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

> (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
>>>>
>>>>
>>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message