couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <B.Cand...@pobox.com>
Subject Re: Performance issue
Date Tue, 03 Nov 2009 22:06:11 GMT
On Tue, Nov 03, 2009 at 11:07:53PM +0200, Sebastian Negomireanu wrote:
> Here is the pcap.

Thanks, nicely readable by
$ tcpdump -r couchdb.pcap -n -s0 -X tcp port 5984 | less

>From this, it is very clear that the delays are at the client side. I
summarise this as:

20:22:18.126308 client HEAD request
20:22:18.127548 couchdb reply
20:22:18.628031 client HEAD request
20:22:18.629850 couchdb reply
20:22:19.128057 client DELETE request
20:22:19.129538 couchdb reply headers
20:22:19.129632 couchdb reply {"ok":true}
20:22:19.630213 client HEAD request
20:22:19.632080 couchdb reply
20:22:20.130202 client PUT request
20:22:20.137190 couchdb reply headers
20:22:20.137291 couchdb reply {"ok":true}
20:22:20.638725 client HEAD request
20:22:20.640478 couchdb reply
20:22:21.140890 client GET request
20:22:21.142721 couchdb reply (404 not found) headers
20:22:21.142808 couchdb reply {"error":"not found", ...}
20:22:21.644430 client POST request with Expect: 100-continue
20:22:21.645963 couchdb reply 100 Continue
20:22:21.646248 client POST body
20:22:21.648031 couchdb reply (201 created) headers
20:22:21.648144 couchdb reply body
20:22:22.154238 client POST request with Expect: 100-continue
20:22:22.155672 couchdb reply 100 Continue
20:22:22.156137 client POST body
20:22:22.157991 couchdb reply (201 created) headers
20:22:22.158071 couchdb reply body
20:22:22.664223 client POST request with Expect: 100-continue
20:22:22.673349 couchdb reply 100 Continue
20:22:22.673712 client POST body
20:22:22.674925 couchdb reply (201 created) headers
20:22:22.675631 couchdb reply body
20:22:23.185424 client GET request to view
20:22:23.193105 couchdb reply headers
20:22:23.193208 couchdb reply body
...

In every case, couchdb is responding promptly to the request. Then
consistently the client is waiting ~500ms before sending the next request.
So you need to find out what is causing this at your side.

My best guess is that this is Nagle in action: see
http://en.wikipedia.org/wiki/Nagle's_algorithm

If you modify your client HTTP framework to set the TCP_NODELAY option on
its socket, the problem may go away. Or, if you arrange for your client to
build the entire HTTP request into a buffer then send it in a single
write(), instead of multiple write()s, this may fix it.

Regards,

Brian.

Mime
View raw message