Mailing-List: contact commits-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Apache Wiki <wikidiffs@apache.org>
To: Apache Wiki <wikidiffs@apache.org>
Date: Mon, 28 Nov 2011 10:59:07 -0000
Message-ID: <20111128105907.18803.91768@eos.apache.org>
Subject: 
 =?utf-8?q?=5BCouchdb_Wiki=5D_Update_of_=22Performance=22_by_FilipeManana?=
Auto-Submitted: auto-generated

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for c=
hange notification.

The "Performance" page has been changed by FilipeManana:
http://wiki.apache.org/couchdb/Performance?action=3Ddiff&rev1=3D11&rev2=3D12

Comment:
Added a note about TCP NO_DELAY

  There is latency overhead making and receiving each request/response.  In=
 general you should do your requests in batches.  Most APIs have some mecha=
nism to do batches, usually by supplying lists of documents or keys in the =
request body.  Be careful what size you pick for the batches.  The larger t=
he batch the more time your client has to spend encoding the items into JSO=
N and more time is spent decoding that number of responses.   Do some bench=
marking with your own configuration and typical data to find the sweet spot=
.  It is likely to be between one and ten thousand documents.
  =

  If you have a fast I/O system then you can also use concurrency - have mu=
ltiple requests/responses at the same time.  This mitigates the latency inv=
olved in assembling JSON, doing the networking and decoding JSON.
+ =

+ As of CouchDB 1.1.0, users often report lower write performance of docume=
nts compared to older releases. The main reason is that this release ships =
with a more recent version of the HTTP server library Mochiweb, which by de=
fault sets the TCP socket option ''SO_NODELAY'' to false. This means that s=
mall data sent to the TCP socket, like the reply to a document write reques=
t (or reading a very small document), will not be sent immediately to the n=
etwork - TCP will buffer it for a while hoping that it will be asked to sen=
d more data through the same socket data and then send all the data at once=
 for increased performance. This TCP buffering behaviour can be disabled vi=
a the .ini configuration for all sockets. Example:
+ =

+ {{{
+ [httpd]
+ socket_options =3D [{nodelay, true}]
+ }}}
+ =

  =

  =3D View generation =3D
  Views with the Javascript view server (default) are extremely slow to gen=
erate when there are a non-trivial number of documents to process.  The gen=
eration process won't even saturate a single CPU let alone your I/O.  The c=
ause is the latency involved in the CouchDB server and seperate couchjs vie=
w server, dramatically indicating how important it is to take latency out o=
f your implementation.