incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: performance issues
Date Mon, 05 Apr 2010 19:09:11 GMT

On Apr 5, 2010, at 2:52 PM, Julian Moritz <>  

> Hi,
> Julian Moritz schrieb:
>> Hi,
> I've just found this via google:
>>> 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.
> 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.
> Regards
> Julian

Hi Julian, it is still true that CouchDB will use only one couchjs  
process for all the map functions in a single design doc. It uses a  
second couchjs for the reduce functions, and of course separate design  
docs get their own processes as well.

In my experience simple view indexing was almost always limited by the  
Erlang VM, so parallelizing was premature. If you've got a modern  
SpiderMonkey and you're still CPU limited perhaps that's no longer the  
case.  Can you remind us of the Couch and SM versions here?


>> 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:
>> function(doc){
>> emit([hash(doc.word), doc.word], null);
>> }
>> and a simple reduce:
>> function(key, values, rereduce){
>> return true;
>> }
>> calling that view with group=true it does what I want.
>> When storing plenty of words to the database, one of my two cpu  
>> cores is
>> used completely by couchjs.
>> 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.
>> Is there a solution for that? Should I use another query-server?
>> Regards
>> Julian

View raw message