Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of jchris@gmail.com designates
 74.125.83.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=content-type:mime-version:subject:from:in-reply-to:date
         :content-transfer-encoding:message-id:references:to:x-mailer;
        b=jNXHkXb/zpNAV8FVhOefQ223OGFrWBA1hrc46tv0y5AJeDDoJSiTZ5LaFgR7Ep9PT+
         loR1vHoX0+8cUpaK0Cr4VHFiq6xSiei//ClCBdAmGNJCNnSDfIqAmhvbvIeN6BB81WfZ
         6ZEuhSrAnJT1/14VdSorNafuMF/flNi7zsNmg=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1077)
Subject: Re: performance issues
From: J Chris Anderson <jchris@gmail.com>
In-Reply-To: <4BBA315B.5010701@julianmoritz.de>
Date: Mon, 5 Apr 2010 12:03:45 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <7FB459A8-6A46-4CC0-818B-AE60B554A673@gmail.com>
References: <4BBA0C4A.9080304@julianmoritz.de>
 <4BBA315B.5010701@julianmoritz.de>
To: user@couchdb.apache.org


On Apr 5, 2010, at 11:52 AM, Julian Moritz wrote:

> Hi,
>=20
> Julian Moritz schrieb:
>> Hi,
>>=20
>=20
> I've just found this via google:
>=20
>>> We don't parallelize view index creation yet, so this is not an
>>> additional problem for you. You can however build two views in
>>> parallel and make use of two cores that way.
>>=20
>=20
> If this is (still) true, view index creation is the bottleneck of my
> application. Hence I'm just playing around and yet using 100% of my
> core, I cannot use CouchDB anymore.
>=20

We rarely see view generation that is actually limited by view-function =
execution speed. The majority of the time the actual bottleneck is disk =
IO. To parallelize view generation the best option is to run a =
CouchDB-Lounge cluster.

It looks like you might be better of removing your reduce function, =
which might also speed things up.

Chris


> Regards
> Julian
>=20
>> I've developed a (in my eyes) simple view. I have a wordlist which =
does
>> not  contain unique words. I want to store it in a view, with every =
word
>> occurring once and ordered by random. Therefore I have a simple view
>> function:
>>=20
>> function(doc){
>> emit([hash(doc.word), doc.word], null);
>> }
>>=20
>> and a simple reduce:
>>=20
>> function(key, values, rereduce){
>> return true;
>> }
>>=20
>> calling that view with group=3Dtrue it does what I want.
>>=20
>> When storing plenty of words to the database, one of my two cpu cores =
is
>> used completely by couchjs.
>>=20
>> Isn't the view built using two (or all) cpu cores? I thought =
(obviously
>> I'm wrong) that it would be calculated in parallel and using a
>> quadro-core (or more cores) would make storing faster.
>>=20
>> Is there a solution for that? Should I use another query-server?
>>=20
>> Regards
>> Julian
>>=20