Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of sivang@gmail.com designates
 209.85.214.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=BYZr++qW3zJW8agxvtKMbtlHZi2NhHj3Gn9z83vXr+PlU67Op7/fjyvN3x0ZTQbNpy
         6xRkAax31LJu2B5VfyOa2GbEMk7vYyakJ3BcHx+yO4TSaYdCFFENPogW+hDz24NcHjln
         SKrI0dtXVb4Ems4jLwk2bDbwK8fd8YBsGojLk=
MIME-Version: 1.0
Sender: sivang@gmail.com
In-Reply-To: <AA80CBB2-D056-4348-A9C3-215997A9002F@apache.org>
References: <2D9A4307-122F-4FA7-BD79-662453A84645@mymedify.com>
	<AA80CBB2-D056-4348-A9C3-215997A9002F@apache.org>
Date: Sat, 7 Aug 2010 14:37:24 +0300
Message-ID: <AANLkTik+6apmdbM8bWGpt1rgjDDOxXZmbUJvff8H+ah9@mail.gmail.com>
Subject: Re: Scalability of _changes api?
From: Sivan Greenberg <sivan@omniqueue.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 <jchris@apache.org> 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 _c=
hanges 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 th=
at with an Erlang filter, as the JS filters run in their own OS process. Co=
uchDB 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 y=
ou will hit long before running an (Erlang) changes filter will be the inse=
rt / update rate of the database itself.
>
> If you were to say, make thousands of concurrent changes requests, with v=
arying since=3DSeq params, that would be the worst case, so you can test th=
at work load if you want to find boundaries conditions. (Bottleneck here wo=
uld be for disk IO reads I think).
>
> Chris
>
>> Thanks,
>> Talib
>
>