CouchDB Performance: 1.6.1 vs 2.1.1

Question

We are looking at upgrading our CouchDB on our RHEL servers from 1.6.1 to 2.1.1. Before we do that, though, we wanted to run a performance test. So we created a JMeter test that goes directly against the database. It does not use any random values, so that the test would be exactly the same, and we could compare the two results. This is just a standalone server, we are not using clustering. I ran the tests the exacts same way for both. I ran the tests for 1.6.1, and then installed 2.1.1 on the same machine. And I created the database new for each test run. [I also updated Erlang to R19.3.]

The results were very shocking:

Average response times: 
1.6.1:   271.15 ms
2.1.1:   494.32 ms

POST and PUTs were really bad ...
POST:
1.6.1:   38.25 ms
2.1.1:   250.18 ms

PUT:
1.6.1:   37.33 ms
2.1.1:   358.76

We are just using the default values for all the config options, except that we changed 1.6.1 to have delayed_commits = false (that is now the default in 2.1.1). I'm wondering if there's some default that changed that would make 2.1.1 so bad.

When I ran the CouchDB setup from the Fauxton UI, it added the following to my local.ini:

[cluster]
n = 1

Is that causing CouchDB to try to use clustering, or is that the same as if there were no entries here at all? One other thing, I deleted the _global_changes database, since it seemed as if it would add extra processing that we didn't need.

Answer 1

Is that causing CouchDB to try to use clustering, or is that the same as if there were no entries here at all?

It's not obvious from your description. If you setup CouchDB 2.0 as clustered then that's how it will work. This is something you should know depending on the setup instructions you followed: http://docs.couchdb.org/en/2.1.1/install/setup.html

You can tell by locating the files on disk and seeing if they are in a shards directory or not.

I'm pretty sure you want at least two, so setting n = 1 doesn't seem like something you should be doing.

If you're trying to run in single node follow the instructions I linked above to do that.

One other thing, I deleted the _global_changes database, since it seemed as if it would add extra processing that we didn't need.

You probably don't want to delete random parts of your database unless there are instructions saying this is OK?