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 <[email protected]>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<[email protected]>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 >>>> >>>> >>> >> >
