Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4395A9B0C for ; Thu, 27 Oct 2011 20:50:14 +0000 (UTC) Received: (qmail 63240 invoked by uid 500); 27 Oct 2011 20:50:12 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 63204 invoked by uid 500); 27 Oct 2011 20:50:12 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 63196 invoked by uid 99); 27 Oct 2011 20:50:12 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 27 Oct 2011 20:50:12 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jens@couchbase.com designates 206.225.164.32 as permitted sender) Received: from [206.225.164.32] (HELO EXHUB020-5.exch020.serverdata.net) (206.225.164.32) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 27 Oct 2011 20:50:06 +0000 Received: from EXVMBX020-1.exch020.serverdata.net ([169.254.4.141]) by EXHUB020-5.exch020.serverdata.net ([206.225.164.32]) with mapi; Thu, 27 Oct 2011 13:49:44 -0700 From: Jens Alfke To: "user@couchdb.apache.org" Date: Thu, 27 Oct 2011 13:49:43 -0700 Subject: Re: High latency (40ms) and low request rate (10 rps) under windows Thread-Topic: High latency (40ms) and low request rate (10 rps) under windows Thread-Index: AcyU6fSt5VSD11SWS+mnTfTKJgpFpQ== Message-ID: References: <31406785.20111025232214@imarto.net> <4EA7178D.40007@gmail.com> <101780326.20111026011900@imarto.net> <4EA7AF0F.80007@gmail.com> <1002823249.20111027032054@imarto.net> <4EA905B4.5000904@gmail.com> <883747569.20111027120911@imarto.net> In-Reply-To: <883747569.20111027120911@imarto.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EE0CB35BC6D444188CCC946945F84242couchbasecom_" MIME-Version: 1.0 --_000_EE0CB35BC6D444188CCC946945F84242couchbasecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Oct 27, 2011, at 1:09 AM, Konstantin Cherkasov wrote: I meant "one day" =3D "once" in the sense that buffer usually does not assu= me durability. In other words, if you choose to buffer the data then you are ready that there is a probability the data can be lost. Face it: the data=92s going to get buffered somewhere. If you don=92t buffe= r it, then either the database server will, or the OS kernel will, or the d= isk controller will. It=92s definitely fastest to let the controller do the= buffering, but since it knows nothing of your file format or even the disk= =92s volume format, the results of data loss are much worse (i.e. file corr= uption.) Doing the buffering at a higher level provides better reliability = at the expense of performance. =97Jens --_000_EE0CB35BC6D444188CCC946945F84242couchbasecom_--