couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Metson <>
Subject Re: Slow filtered _changes feed
Date Wed, 20 Oct 2010 10:43:14 GMT
	One thought: do you query the last N changes or the whole feed? If I  
apply a simple filter to my test database it is slow to get the full  
result, but it's relatviely fast to skip to the more recent changes  
(the ones I've already consumed and go from there.

Also, the _changes feed streams the documents down to the client - can  
your client/server deal with a streaming response?

On 20 Oct 2010, at 03:44, Cory Zue wrote:

> Howdy,
> I'm bringing up a problem I chatted about with a few folks with on IRC
> today but was unable to solve.  My app is using the _changes feed to
> detect what updates need to go to particular clients (in this case
> cell phones) based on some filtered information the phones send up in
> the sync request.  The flow looks something like:
> Phone ---HTTP POST---> Server
> Server ---filtered _changes---> CouchDB
> [Server prepares couch results for phone]
> Server ---Data Payload---> Phone
> All of the above represents a single HTTP POST and response between
> the phone and server.
> The problem I am seeing is that hitting the _changes feed from the
> server is prohibitively slow, and these requests are timing out before
> the server can send data back down to the phone.
> I was led to believe on IRC that changing my filter from javascript to
> erlang would drastically increase performance, but I'm not observing
> this at all.  In fact the erlang version seems slightly slower.
> I setup an erlang view server following these instructions:
> Am I missing something?  Is my erlang so bad as to negate the
> increased performance gain from switching over?  Was I lied to?  Is my
> whole approach dumb and do I need to implement filtered caching inside
> my server and outside of couch?
> Any thoughts or feedback would be much appreciated.
> thanks,
> Cory

View raw message