Full DP5 (current master) environment is much slower indexing data, and querying it, compared to stand alone CouchDB environment

Indexing exactly the same data in a full development environment (clean repo checkout, tlm make) with 1 node (started via cluster_run -n 1) is much slower compared to the case where we run only our CouchDB fork to index the same data (2+ times slower).

Steps

1. Full environment:

Do a clean checkout of master (dp5) and run TLM's make target.
Start a 1 node cluster with ns_server's cluster_run script like this:

$ export COUCHBASE_NUM_VBUCKETS=64
$ ./cluster_run --nodes=1

In another shell, run ns_server's cluster_connect script:

$ ./cluster_connect -n 1

Wait for the rebalance to finish and then shutdown the node (go to former console/terminal and just press Ctrl+C).

Then copy the test database files into ns_server/couch/0/default/ overriding the existing files.
Restart the cluster by running again:

$ export COUCHBASE_NUM_VBUCKETS=64
$ ./cluster_run --nodes=1

Wait for the startup to finish (20 seconds or whatever) and then in another shell trigger an index build:

$ time curl 'http://localhost:9500/default/_design/test/_view/view1?limit=10&stale=false'

Wait for the curl command to return. The indexing time is also logged by the couchdb component, with a log level 'info', in the console and log file. Example of what is logged:

[couchdb:info] [2012-04-19 19:58:50] [n_0@127.0.0.1:<0.1092.0>:couch_log:info:39] Set view `default`, main group `_design/test`, updater finished
Indexing time: 188.571 seconds
Blocked time: 0.000 seconds
Inserted IDs: 1000000
Deleted IDs: 0
Inserted KVs: 1000000
Deleted KVs: 0
Cleaned KVs: 0

1. Standalone couchdb

Do a clean checkout of CouchDB:

$ cd ~/mydir
$ git clone git://github.com/couchbase/couchdb.git

Build CouchDB like this:

$ cd couchdb
$ ./bootstrap

1. pass --with-v8-include, --with-v8-lib, --with-erlang, etc if needed
   $ ./configure
   $ make dev

Run CouchDB like this:

$ ./utils/run

Then copy the test database files into mydir/couchdb/tmp/lib (the files will then live inside mydir/couchdb/tmp/lib/default).

Trigger an index build from another console/terminal:

$ curl -H 'Content-Type: application/json' -X POST http://localhost:5984/_set_view/default/_design/test/_define \
-d '

{ "number_partitions": 64, "passive_partitions": [], "active_partitions": [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63] }

'

$ time curl 'http://localhost:5984/_set_view/default/_design/test/_view/view1?limit=10&stale=false'

Wait for curl to finish. The indexing time can also be found in the console or couchdb's log file (mydir/couchdb/log/couch.log), e.g.:

[info] [<0.180.0>] Set view `default`, main group `_design/test`, updater finished
Indexing time: 102.557 seconds
Blocked time: 0.000 seconds
Inserted IDs: 1000000
Deleted IDs: 0
Inserted KVs: 1000000
Deleted KVs: 0
Cleaned KVs: 0

Test database files at:

http://dl.dropbox.com/u/25067962/MB-5111-db-files.tgz

Also, querying the view is about 2 times slower with Couchbase Server compared to the case where we query through standalone CouchDB.
Steps to reproduce:

$ git clone git://github.com/couchbaselabs/view_query_perf.git
$ cd view_query_perf
$ make

Start a single node cluster with ./cluster_run --nodes=1, like in the indexing example above for indexing, and query the view, after fully built, with:

$ ./run --query-url 'http://localhost:9500/default/_design/test/_view/view1?limit=10&stale=update_after' --queries 10000 --workers 1
Spawning 1 workers, each will perform 10000 view queries
View query URL is: http://localhost:9500/default/_design/test/_view/view1?limit=10&stale=update_after

Waiting for workers to finish...

All workers finished. Final statistics are:

Average response time: 2.987331500000006ms
Highest response time: 39.631ms
Lowest response time: 2.624ms
Response time std dev: 0.44975173307920663ms

1. of errors: 0

Then start standalone CouchDB, via the ./utils/run script as described above for indexing, and query the view (after it's fully built) like this:

$ ./run --query-url 'http://localhost:5984/_view_merge?limit=10&stale=update_after' --query-body '{ "views": { "sets": { "default":

{ "view": "test/view1", "partitions": [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63] }

} } }' --queries 10000 --workers 1
Spawning 1 workers, each will perform 10000 view queries
View query URL is: http://localhost:5984/_view_merge?limit=10&stale=update_after

Waiting for workers to finish...

All workers finished. Final statistics are:

Average response time: 1.6851034000000091ms
Highest response time: 36.774ms
Lowest response time: 1.467ms
Response time std dev: 0.38282514377773025ms

1. of errors: 0