Actually, it's probably better to use no server side filter and just use a filter on the client so long as your update frequency isn't so enormous that it would overload a single client.
-Mikeal On Sat, Aug 7, 2010 at 4:37 AM, Sivan Greenberg <[email protected]> wrote: > As I am also using a JS filter and fear the performance and load > consequences, how does one go about writing an erlang filter? > > -SIvan > > On Fri, Aug 6, 2010 at 11:55 PM, J Chris Anderson <[email protected]> > wrote: > > > > On Aug 6, 2010, at 1:38 PM, Talib Sharif wrote: > > > >> Hey All, > >> > >> Do people have experience with the scalability and performance of the > _changes api in general, and especially when using with filters? > >> > >> How many connections can be kept open? > >> > > > > If you use a JavaScript filter, you will have more limited concurrency > that with an Erlang filter, as the JS filters run in their own OS process. > CouchDB tries to be reasonably efficient with these, but they are still much > more heavyweight than the Erlang ones. > > > >> And is the changes api function of size/updates/total_no_documents? > >> > > > > I think the _changes API should have no scalability issues, as the wall > you will hit long before running an (Erlang) changes filter will be the > insert / update rate of the database itself. > > > > If you were to say, make thousands of concurrent changes requests, with > varying since=Seq params, that would be the worst case, so you can test that > work load if you want to find boundaries conditions. (Bottleneck here would > be for disk IO reads I think). > > > > Chris > > > >> Thanks, > >> Talib > > > > >
