couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Couchdb Wiki] Update of "Performance" by FilipeManana
Date Mon, 28 Nov 2011 10:59:07 GMT
Dear Wiki user,

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

The "Performance" page has been changed by FilipeManana:

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 mechanism 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 the batch the more time your client has to spend encoding the items into JSON
and more time is spent decoding that number of responses.   Do some benchmarking 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 multiple requests/responses
at the same time.  This mitigates the latency involved in assembling JSON, doing the networking
and decoding JSON.
+ As of CouchDB 1.1.0, users often report lower write performance of documents 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 default sets the TCP socket option ''SO_NODELAY'' to
false. This means that small data sent to the TCP socket, like the reply to a document write
request (or reading a very small document), will not be sent immediately to the network -
TCP will buffer it for a while hoping that it will be asked to send 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 via the .ini configuration for all sockets. Example:
+ {{{
+ [httpd]
+ socket_options = [{nodelay, true}]
+ }}}
  = View generation =
  Views with the Javascript view server (default) are extremely slow to generate when there
are a non-trivial number of documents to process.  The generation process won't even saturate
a single CPU let alone your I/O.  The cause is the latency involved in the CouchDB server
and seperate couchjs view server, dramatically indicating how important it is to take latency
out of your implementation.

View raw message