Home/ Questions/Q 1033961
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T14:18:49+00:00

First, here’s my original question that spawned all of this . I’m using Appcelerator

  • 0

First, here’s my original question that spawned all of this.

I’m using Appcelerator Titanium to develop an iPhone app (eventually Android too). I’m connecting to CouchDB’s port directly by using Titanium’s Titanium.Network.TCPSocket object. I believe it utilizes the Apple SDK’s CFSocket/NSStream class.

Once connected, I simply write:

'GET /mydb/_changes?filter=app/myfilter&feed=continuous&gameid=4&heartbeat=30000 HTTP/1.1\r\n\r\n'

directly to the socket. It keeps it open “forever” and returns JSON data whenever the db is updated and matches the filter and change request. Cool.

I’m wondering, is it ok to connect directly to CouchDB’s socket like this, or would I be better off opening the socket to node.js instead, and maybe using this CouchDB node.js module to handle the CouchDB proxy through node.js?

My main concern is performance. I just don’t have enough experience with CouchDB to know if hitting its socket and passing faux HTTP requests directly is good practice or not. Looking for experience and opinions on any ramifications or alternate suggestions.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    It’s me again. 🙂

    CouchDB inherits super concurrency handling from Erlang, the language it was written in. Erlang uses lightweight processes and message passing between those processes to achieve excellent performance under high concurrent load. It will take advantage of all cpu cores, too.

    Nodejs runs a single process and basically only does one thing at a time within that process. Its event-based, non-blocking IO approach does allow it to multitask while it waits for chunks of IO but it still only does one thing at a time.

    Both should easily handle tens of thousands of connections, but I would expect CouchDB to handle concurrency better (and with less effort on your part) than Node. And keep in mind that Node adds some latency if you put it in front of CouchDB. That may only be noticeable if you have them on different machines, though.

    Writing directly to Couch via TCPSocket is a-ok as long as your write a well-formed HTTP request that follows the spec. (You’re not passing a faux request…that’s a real HTTP request you’re sending just like any other.)

    Note: HTTP 1.1 does require you to include a Host header in the request, so you’ll need to correct your code to reflect that OR just use HTTP 1.0 which doesn’t require it to keep things simple. (I’m curious why you’re not using Titanium.Network.HTTPClient. Does it only give you the request body after the request finishes or something?)

    Anyway, CouchDB can totally handle direct connections and–unless you put a lot of effort into your Node proxy–it’s probably going to give users a better experience when you have 100k of them playing the game at once.

    EDIT: If you use Node write an actual HTTP proxy. That will run a lot faster than using the module you provided and be simpler to implement. (Rather than defining your own API that then makes requests to Couch you can just pass certain requests on to CouchDB and block others, say, for security reasons.

    Also take a look at how “multinode” works:
    http://www.sitepen.com/blog/2010/07/14/multi-node-concurrent-nodejs-http-server/

    • 0