Quick CouchDB Javascript engine replacement test (couchjs)

Somewhere online I had read about a new project from a guy at IrisCouch to replace the built in Javascript engine that comes with CouchDB.

You can see his project on GitHub here: https://github.com/iriscouch/couchjs

The instructions for replacing the Javascript engine of CouchDB are pretty simple. I spent most of my time trying to fight to install the right version of node.js and npm on my local Ubuntu VM.

Unfortunately after switching to the new couchjs engine I didn’t notice any performance gains. I’m not exactly sure what the motivation is for writing a new Javascript engine for CouchDB if not for performance. Maybe since I’m running BigCouch the advantages are negated? The GitHub site says the new couchjs Javascript engine is using V8. Do you remember the first time you ran a Javascript heavy feature in Chrome? It was much faster, right? I was very excited to see a performance gain of 10-20% (much like Chrome’s performance gains), but instead saw no visible, or measured, gains.

Bummer.

Something to keep an eye on though in case I need to squeeze every last drop of performance out of CouchDB.

Quick CouchDB Javascript engine replacement test (couchjs)

4 thoughts on “Quick CouchDB Javascript engine replacement test (couchjs)

  1. The main point of the new couchjs engine was never performance gains: both SpiderMonkey and V8 are pretty fast.

    It’s more about deployment. SpiderMonkey is quite frankly dependency hell, it needs some like 15 year old version of autoconf and some random patches and who knows what all else just to build…and then you find out you built the wrong checkout number on accident and have to start over. (I gave up trying to build CouchDB until IrisCouch released build-couchdb.) Whereas V8 is a bit more modern, a bit more designed for embedding, a bit better versioned and thanks to node.js WAAAAAY more mindshare for using it on the serverside.

  2. ryan1234 says:

    Here are my notes from setting up a BigCouch cluster. Hope they help:

    ip1 = ip address of your first big couch node
    ip2 = ip address of your second big couch node
    second-node-name = name of the second big couch node (you can check this when looking at port 5986 I believe.

    curl -X PUT http://ip1:5986/nodes/second-node-name@ip2 -d {}

    – change /opt/bigcouch/etc/vm.args to use “-sname”
    – change /opt/bigcouch/etc/vm.args -sname value to unique values for each node
    – first ip is the internal ip of the master node
    – 5986 matters. don’t use 5984
    – second hostname@ip is the second node name and the internal DNS for the second node
    – run on master, primary node, first machine created
    – open port 5984 (http web tool)
    – open port 5986 (erlang back end replication)
    – open port 4369 (erlang)
    – modify /opt/bigcouch/etc/vm.args and include the following:
    # Limiting the ports for the Erlang kernel
    -kernel inet_dist_listen_min 10000
    -kernel inet_dist_listen_max 11000
    – open ports 10000 through 11000 (erlang)
    – also make sure bind_address in config /opt/bigcouch/etc is set to 0.0.0.0, not 127.0.0.1
    – when finished, the 5986 portal, nodes database … the document count is equal to number of nodes. if less, then it’s wrong.
    – sometimes couch resolves the private dns in an interesting way. best thing to do is create nodes separately, then navigate to :5986 and look in nodes database. see what private hostname couch wants and then use _that_ to go forward.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s