couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanley Iriele <>
Subject Re: Http 1.1 keep alive
Date Tue, 05 Nov 2013 23:57:38 GMT
This snippet I found in the couchdb core api section of the documentation
seems a bit misleading to me. It looks like its saying" keeping connections
is hard so tear them down"...I know that it doesn't mean that because of
what was just explained here and because I've used couchdb in production
for many things:

One of the aspects of the HTTP protocol that CouchDB uses is that it is
stateless. What does that mean? When talking to CouchDB you need to make
requests. Making a request includes opening a network connection to
CouchDB, exchanging bytes, and closing the connection. This is done every
time you make a request. Other protocols allow you to open a connection,
exchange bytes, keep the connection open, exchange more bytes later – maybe
depending on the bytes you exchanged at the beginning – and eventually
close the connection. Holding a connection open for later use requires the
server to do extra work. One common pattern is that for the lifetime of a
connection, the client has a consistent and static view of the data on the
server. Managing huge amounts of parallel connections is a significant
amount of work. HTTP connections are usually short-lived, and making the
same guarantees is a lot easier. As a result, CouchDB can handle many more
concurrent connections.
On Nov 5, 2013 2:56 PM, "Jens Alfke" <> wrote:

> On Nov 5, 2013, at 1:46 PM, Stanley Iriele <> wrote:
> > Does couchdb respect http keep alives?... Most of ReSTs pain comes from
> > creating and tearing down connections...
> Every modern server or client should support keep-alive; as Bob says, it’s
> a basic feature of HTTP 1.1. What REST-based systems have you been using
> that don’t?
> —Jens

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