I found almost 7-8 times faster when I use hovercraft compare to http interfaced client like couchbeam or ecouch http://pmsenthilkumar.blogspot.com/2009/10/native-erlang-interface-to-couchdb.html, this is mainly due to too many serialization and http transport latency, my brief look at native client is here http://pmsenthilkumar.blogspot.com/2009/10/native-erlang-interface-to-couchdb.html Besides, I am also trying to embed couchdb with my other Erlang application but when I looked at the startup parameter of the couchdb it is not a naive job to eliminate all the hard work of shell script.
On Sat, Oct 31, 2009 at 5:52 PM, Senthilkumar Peelikkampatti < [email protected]> wrote: > I fixed hovercraft and it is now sync up date with latest couchdb 0.11xxx. > My fork is @ http://github.com/sendtopms/hovercraft > > > On Wed, Oct 28, 2009 at 3:20 PM, Paul Davis > <[email protected]>wrote: > >> Zoltan, (Got the A right!) >> >> On Wed, Oct 28, 2009 at 4:06 PM, Zoltan Lajos Kis <[email protected]> >> wrote: >> > Hello all, >> > >> > Has anyone been experimenting with running CouchDB as an Erlang only >> > application? What I would love to have is: >> > - stick CouchDB into my lib/ directory, and have it run as part of my >> > release (everything running in a single Erlang VM). >> >> We've done some work to make CouchDB startable via application:start() >> as per Erlang semantics. This should work in theory but there still >> might be gotchyas with the base install. I know people have >> successfully run it as a dependent app though. >> >> > - use Erlang views only (is erlview running within the same VM? is it >> > up-to-date with CouchDB features?) >> >> Native Erlang views can be enabled with a config option. They're in >> trunk now and will remain consistent with the JavaScript server >> implementation. >> >> > - access CouchDB via an Erlang interface (is hovercraft still running? >> does >> > it support all features available via http?) >> >> Not sure if Hovercraft is up to date with trunk. I think I heard >> someone on IRC say there was a minor version difference that was minor >> to resolve. >> >> > - no dependency on ICU, curl and SpiderMonkey (as I would not need them >> for >> > anything) >> >> To remove the ICU dependency you'll have to patch CouchDB because its >> a linked in driver that's required for collation regardless of view >> server. >> >> Curl and Spidermonkey could be removed as install time dependencies >> fairly easily by discarding couchjs after a build and updating the >> configuration to not attempt to use it. I think some parts of the auth >> code depend on having the JS view server available but you could ixnay >> that pretty easily by giving it an Erlang implementation. Its a pretty >> simple view IIRC. >> >> For build time dependencies, I don't foresee removing them. Though I >> could be convinced if the patch to the build system isn't overly >> intrusive. >> >> > Any pointers to references, case studies, whatever is much appreciated! >> > >> > Regards, >> > ZoltAn. >> >> I've heard of people running as a subordinate in a VM but have no >> direct experience myself. As I recall they basically built CouchDB and >> then installed into their Erlang package for distribution. Or some >> such. It may take a bit of effort as its not use case that's had lots >> of patches submitted. >> >> HTH, >> Paul Davis >> > >
