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 jchris@gmail.com designates
 209.85.212.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=from:mime-version:content-type:subject:date:in-reply-to:to
         :references:message-id:x-mailer;
        b=jO8mv9EYvNRtl8elEKuWp1Yi5Ab6uxjtM/bjNK2Zbb536p5fvuaij7evS1bXiPfkTP
         Y/u/4PMJksaUFtsYo9uTN9wqTcS8jr+P7fpt/RQx8DKhMrHkZZczUHj+QpmwGvRkQndr
         eyRliYlhR4u0hEWVPbKmtsMS2zDAEH/TqnTf8=
From: J Chris Anderson <jchris@gmail.com>
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/alternative; boundary=Apple-Mail-3--601050620
Subject: Re: delayed_commits false
Date: Mon, 5 Jul 2010 11:17:39 -0700
In-Reply-To: <AANLkTikBD3dPFFsNFd0h9lbJFG4o-RrZiMThbkog_haW@mail.gmail.com>
To: dev@couchdb.apache.org
References: <4C31FF1A.30002@gmail.com>
 <AANLkTikBD3dPFFsNFd0h9lbJFG4o-RrZiMThbkog_haW@mail.gmail.com>
Message-Id: <7B20AA6A-CB1B-4E30-A4B6-4853B72922B2@gmail.com>

--Apple-Mail-3--601050620
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

For a relatively sane look at the tradeoff's we're talking about, this =
is a good resource:

http://developer.postgresql.org/pgdocs/postgres/runtime-config-wal.html

I wish it was simple to write a heuristic which would detect single =
serialized client workloads, and delay commits, but I don't think it is.

I lean (slightly) toward leaving delayed_commits =3D true because the =
worst case scenario, even in the case of a crash, isn't data corruption, =
just lost data from the most recent activity.

It is also worth noting that there is an API to ensure_full_commit aside =
from the configuration value, so if you have high-value data you are =
writing, you can call ensure_full_commit (or use a header value to make =
the last PUT or POST operation force full commit)

I think this is worth discussing. I'm not strongly in favor of the =
delayed_commit=3Dtrue setting, but I do think it is slightly more =
user-friendly...

Chris

On Jul 5, 2010, at 10:02 AM, Mikeal Rogers wrote:

> For the concurrent performance tests I wrote in relaximation it's =
actually
> better to run with delayed_commits off because it measures the =
roundtrip
> time of all the concurrent clients.
>=20
> The reason it's enabled by default is because of apache-bench and =
other
> single writer performance test tools. =46rom what I've seen, it =
doesn't
> actually improve write performance under concurrent load and leads to =
a kind
> of blocking behavior when you start throwing too many writes at it =
than it
> can fsync in a second. The degradation in performance is pretty huge =
with
> this "blocking" in my concurrent tests.
>=20
> I don't know of a lot of good concurrent performance test tools which =
is why
> I went and wrote one. But, it only tests CouchDB and people love to =
pick up
> one of these tools that tests a bunch of other dbs (poorly) and be =
like
> "CouchDB is slow" because they are using a single writer.
>=20
> But, IMHO it's better to ship with more guarantees about consistency =
than
> optimized for crappy perf tools.
>=20
> -Mikeal
>=20
> On Mon, Jul 5, 2010 at 8:49 AM, Volker Mische =
<volker.mische@gmail.com>wrote:
>=20
>> 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
>>=20
>> Cheers,
>> Volker
>>=20


--Apple-Mail-3--601050620--