Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 58635 invoked from network); 6 Jul 2010 22:07:00 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 6 Jul 2010 22:07:00 -0000 Received: (qmail 91564 invoked by uid 500); 6 Jul 2010 22:07:00 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 91512 invoked by uid 500); 6 Jul 2010 22:06:59 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 91503 invoked by uid 99); 6 Jul 2010 22:06:59 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Jul 2010 22:06:59 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.68.5.17] (HELO relay03.pair.com) (209.68.5.17) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 06 Jul 2010 22:06:50 +0000 Received: (qmail 22518 invoked from network); 6 Jul 2010 22:06:28 -0000 Received: from 74.1.186.35 (HELO ?10.0.1.205?) (74.1.186.35) by relay03.pair.com with SMTP; 6 Jul 2010 22:06:28 -0000 X-pair-Authenticated: 74.1.186.35 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) Subject: Re: delayed_commits false From: Damien Katz In-Reply-To: <4C31FF1A.30002@gmail.com> Date: Tue, 6 Jul 2010 15:06:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C31FF1A.30002@gmail.com> To: dev@couchdb.apache.org X-Mailer: Apple Mail (2.1081) X-Virus-Checked: Checked by ClamAV on apache.org On Jul 5, 2010, at 8:49 AM, Volker Mische wrote: > Hi All, >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > *I know that in reality people don't >=20 > I would like to see delayed_commits=3Dfalse 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/Core= Data/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 >=20 > Cheers, > Volker