I wanted to run couchdb under emulator but the problem with erl emulator is, it is not inheriting or obeying sudo command. I didn't plan well before installing couchdb so that it could run as logged in user. So I tried something like below to make it work on my macbook OS X (10.5.8)
1. sudo bash
2. set ERL_LIBS
3. export it
4. erl
Actual steps are
1. sudo bash (OR) sudo su
2. ERL_LIBS=/usr/local/lib/couchdb/erlang/lib --- path where couchdb is installed
3. export ERL_LIBS
4. echo $ERL_LIBS --- to verify the var is set properly
5. erl It worked finally...
Saturday, October 31, 2009
Saturday, October 24, 2009
Native Erlang Interface to CouchDB
Http Client
In my application I am using couchbeam as erlang client utility. It is under heavily developed and improved by benoitc. It is one of the excellent http based couchdb erlang client.
Native Client
There is an interface which sits along with couchdb binaries called hovercraft. It looks like not maintained by its developer and it was not working as it is not retrofitted to new couchdb changes. I fixed those things by forking it (http://github.com/sendtopms/hovercraft).
Performance difference
It is native erlang client. So compare to any other http based erlang couchdb client it has advantage of talking to couchdb using erlang terms. So erlang->json ->erlang serialization is avoided. In my ad-hoc testing, I just had a document in couchdb and created view and accessed it through above client.
Couchbeam took 6472microsec - 7331 microsec
Hovercraft took 994 microsec - 1057 microsec.
Will this # matter? It is not humanly noticeable to find the difference but when no of request increases throughput will increase with native view but need to deal with Erlang.
Http client has advantages over native as
1. Easy to loadbalance using HAProxy or nginx or Apache
2. it is dead easy to set up Master to Slave configuration as Load is balanced in the DB request layer so Create/Update/Delete (CUD) can easily be routed to master, in case of native client, LB can be done at front end or presentation layer, but routing to master for CUD is quite complicated if it has session association and state management, but if it is designed and architected from the start it is quite simple to model. After all, native client is 6-7 times more efficient to http based client.
In my application I am using couchbeam as erlang client utility. It is under heavily developed and improved by benoitc. It is one of the excellent http based couchdb erlang client.
Native Client
There is an interface which sits along with couchdb binaries called hovercraft. It looks like not maintained by its developer and it was not working as it is not retrofitted to new couchdb changes. I fixed those things by forking it (http://github.com/sendtopms/hovercraft).
Performance difference
It is native erlang client. So compare to any other http based erlang couchdb client it has advantage of talking to couchdb using erlang terms. So erlang->json ->erlang serialization is avoided. In my ad-hoc testing, I just had a document in couchdb and created view and accessed it through above client.
Couchbeam took 6472microsec - 7331 microsec
Hovercraft took 994 microsec - 1057 microsec.
Will this # matter? It is not humanly noticeable to find the difference but when no of request increases throughput will increase with native view but need to deal with Erlang.
Http client has advantages over native as
1. Easy to loadbalance using HAProxy or nginx or Apache
2. it is dead easy to set up Master to Slave configuration as Load is balanced in the DB request layer so Create/Update/Delete (CUD) can easily be routed to master, in case of native client, LB can be done at front end or presentation layer, but routing to master for CUD is quite complicated if it has session association and state management, but if it is designed and architected from the start it is quite simple to model. After all, native client is 6-7 times more efficient to http based client.
Subscribe to:
Posts (Atom)