incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Cheng <>
Subject Re: CouchDB performance
Date Wed, 17 Aug 2011 03:18:35 GMT
On Tue, Aug 16, 2011 at 7:49 PM, Jens Alfke <> wrote:

> On Aug 16, 2011, at 5:08 PM, John Cheng wrote:
> was the bottleneck? It also points out that client code for CouchDB
> access may not be easy to implement (I'm not familiar with the
> equivalent of java.nio API in Python, for example). It makes me
> hesitant to recommend using Python with CouchDB right now.
> Why? Asynchrony isn’t rocket science, and last I checked you could do
> asynchronous (or multithreaded) HTTP access in Python. (Isn’t the Twisted
> framework all about async networking?)

Twisted might have a good async networking library, but it is not something
I am familiar with. I can say that I've seen really good performance with an
async HttpClient when using Java, but I can't say the same about a framework
that I've never worked with before.

What' s imporatnt is that I'm curious to see if anyone else is seeing the
same kind of behavior that I've observed. It could help uncover some
unexpected performance regression in v 1.10.0.

> BTW, are you using the bulk-insert API or sending a separate HTTP request
> for every document?
> —Jens

I am using a separate HTTP request for every document in every case:

* python-couchdb API
* Traditional HttpClient API ( ThreadSafeHttpClient with a large connection
pool )
* Async HttpClient

I can probably get much better performance with the bulk-insert API, but I'm
not trying to do a performance benchmark here (performance benchmarks are
almost always pointless). I'm just documenting the different behaviors of
CouchDB so I have better understanding of CouchDB.

My python-couchdb code could use a bit of optimization, starting with using
the 'batch=ok' parameter on inserts. However, that doesn't explain the
drastic performance difference between testing against CouchDB 0.10.0 and
1.1.0. Something is wrong there and I'm not able to identify what it is.

John L Cheng

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message