couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: Optimizing chunked transfer-encoding and the impact on clients
Date Wed, 22 Jul 2015 10:23:10 GMT

nice one Adam! :)

As I see it, here are our options:

1. don’t apply this

2. apply this, but disable it by default and let people opt in, either
  - on a per-request basis like _all_docs?multichunkinator=true
  - on a per-instance config basis: [httpd] multichunkinator=true

3. apply this and enable it by default and let people opt out as per 2. with false as the
  - this requires breaking BC and documenting the upgrade path

4. apply this, enable by default and leave no way back
  - BC break needs to be set up as per 3

For either 2. or 3. we get the opportunity of a nice bikeshed over the name of the query param
/ config value.

I think 1. is not a good idea.

2. is a good choice, if we discover that this would cause major inconveniences for lots of
people in the field (we then could think about swapping this to be the default in 3.0.0).

4. seems needlessly aggressive.

Given that this is not a major issue (as per our information now), I’d be confident with
3. making 2.0 the BC breaking version number.

Once 2.0.0 betas come out, I’d like to work with all the major CouchDB clients to ensure
compatibility, we should find out then, the latest, whether we need to reverse our stance
to, say, 2.

This will require some extra work to allow either behaviour and configuration, but I think
that’d be worth it.

Did I miss anything?


> On 21 Jul 2015, at 17:42, Adam Kocoloski <> wrote:
> Hi all,
> CouchDB uses the chunked transfer-encoding capability of HTTP/1.1 to stream _all_docs,
_changes, _view and similar responses to clients. We have always sent each row of these responses
in a dedicated chunk. Coalescing multiple rows into a single chunk is more efficient and yields
throughput improvements of approximately 30%, but this could break clients that have implicitly
relied on the row-per-chunk organization.
> So — do any of you knowingly rely on this behavior? How difficult would it be to accommodate
this change? Thanks,
> Adam
> P.S. more details on this topic can be found in COUCHDB-2724 and associated Pull Requests:

Professional Support for Apache CouchDB:

View raw message