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: http://wiki.apache.org/couchdb/Performance?action=diff&rev1=11&rev2=12 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 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.
