Views performance questions

Couchbase Server
1

Hi there,

I have a couple of unrelated views performance questions:

  1. Is there a performance penalty to define a view with many equal keys? For example, this map function:

function (doc, meta) {
if(meta.expiration != 0)
emit(1, null);
}

  1. Is there a performance drawback to store a development view design document on the production server? Shouldn’t it be removed after the publishing the views into production?

  2. When a new view is added to a design document and it is being published, it seems that also the existing view(s) of that design document will be re-created, even though their definition hasn’t been changed. Is this a correct impression (we’re speaking about the Couchbase 2.2 Server here).

  3. I have the impression that after reaching some threshold in the disk queue size, Couchbase would stop accepting get/set commands until the situation relieves again. Is this some fixed threshold that I could monitor and change my code accordingly? As a background of the question: I had a script that would set TTL of several millions documents using a “multi” variant of touch. The first run of the script has brought the whole Couchbase completely down, presumably by overfilling the disk queue.

Thanks and best regards,
Maxim

2

Hi,

Ok so let me walk through the questions

  1. This should not cause any trouble, the key in the view is actually going be
    comprised of the document key and the key you emit so it won’t be exact
    duplicates, also a Btree, which is the format for the index, is in general
    faster by design on sequential inserts so I think you are good with that. It
    might still make sense to split the keys up so it allows to process the view in
    groups for example.

  2. Couchbase server will save the design document as a new version and therefor
    needs to ajust the views mapped to this design document. As far as I know there
    is nothing implemented in 2.2 to detect if a view has not changed in a new
    design document version.

  3. There is actually an exception for exactly this case, couchbase with respond
    with a temporary out of memory error in case it can’t write to the disk fast
    enough, see http://www.couchbase.com/communities/q-and-a/failed-process-response-temporary-failure-bulk-insert-using-executestore and http://docs.couchbase.com/couchbase-sdk-net-1.3/#bulk-load-and-exponential-backoff for more details.