Return-Path: Delivered-To: apmail-incubator-couchdb-user-archive@locus.apache.org Received: (qmail 32579 invoked from network); 11 Sep 2008 19:32:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 11 Sep 2008 19:32:26 -0000 Received: (qmail 98459 invoked by uid 500); 11 Sep 2008 19:32:22 -0000 Delivered-To: apmail-incubator-couchdb-user-archive@incubator.apache.org Received: (qmail 98178 invoked by uid 500); 11 Sep 2008 19:32:22 -0000 Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: couchdb-user@incubator.apache.org Delivered-To: mailing list couchdb-user@incubator.apache.org Received: (qmail 98167 invoked by uid 99); 11 Sep 2008 19:32:22 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Sep 2008 12:32:22 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of william.kinney@gmail.com designates 216.239.58.189 as permitted sender) Received: from [216.239.58.189] (HELO gv-out-0910.google.com) (216.239.58.189) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Sep 2008 19:31:21 +0000 Received: by gv-out-0910.google.com with SMTP id i36so283982gve.17 for ; Thu, 11 Sep 2008 12:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=zCxtUbNu9yzgJTXhN6sIcidYJ3xQjHzJUe7TwcZxvpE=; b=BoCEAo9RoH+7qQdYUzoIWvb5WXtdVP8KxCiSEse1JihKjnUUvZh+gBZcpYiQGSHrZK XqMAIURGBypuvcSi2U0B05MJ4FrlP9bvNFoZozFnO1FZentTxRVQDEYwbZ0pWJBTgWPz jfnoLR+ftfT+Se0RJ5ZsykUe8cXmENXXOPGmU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=Y7jxrxXFaHTGgPlhRQMPpw+kIIp8ZtB75Ewantvs/ZRYCopzNxLa5zHmjW9c6obyVL +V5Fehgp8k2Iw/JiI+1gaFHFVGgTuzoaZF+I3juFSGusB5Mkqmy9iLgzkKYADGKDwcg5 W7HxuAS3KE4Vz8OxuShelQeOgrDgNiAp8t/Kk= Received: by 10.180.206.12 with SMTP id d12mr2546274bkg.33.1221161494551; Thu, 11 Sep 2008 12:31:34 -0700 (PDT) Received: by 10.180.218.2 with HTTP; Thu, 11 Sep 2008 12:31:34 -0700 (PDT) Message-ID: <928bdd8e0809111231t4c17f7e3q9eec1d44bee99140@mail.gmail.com> Date: Thu, 11 Sep 2008 15:31:34 -0400 From: "william kinney" To: couchdb-user@incubator.apache.org Subject: Re: view access keeps timing out In-Reply-To: <7c40ded80809111044h694a671cta793be9a161ef575@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_32375_9321502.1221161494552" References: <928bdd8e0809101925q1f5963ccsca8e0425a9b289eb@mail.gmail.com> <928bdd8e0809111011y7851e58flb60d691b4826e5d5@mail.gmail.com> <7c40ded80809111044h694a671cta793be9a161ef575@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_32375_9321502.1221161494552 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I simplified the map function to: function(doc) { emit(doc._id, doc); } and with count=3&update=false it is still timing out. I'm not sure what is going on. I forgot to mention, the server is a vmware image...but I don't think that has anything do it with it (unless the disk io is being mangled by vmware?). I have another database of 5000 records, and it's not having an issue in accessing some of the views, even after some updates. Could it be something in the data that is making the views fail? The only difference I can see between the two databases is that the one that is failing I created the views after inserting all 10k documents, the 5k it was before and somewhat incrementally updated as it grew. I suppose I'll try populating another database of 10k docs and see what happens. I wish there was a way I could see how the view is progressing, other than requesting and waiting. Thanks, Will On Thu, Sep 11, 2008 at 1:44 PM, Jeremy Wall wrote: > are you trying to return all of the documents at once? does it improve if > you restrict the results with a count=100 or similar? I can possibly see a > scenario where it might time out just trying to server several thousand > documents to you at once. CouchDB doesn't exactly stream the documents to > you one at a time like a sql database might. > > On Thu, Sep 11, 2008 at 12:11 PM, william kinney > wrote: > > > thanks for those! I was googling trying to find example reduce functions, > > in > > vain. > > > > It seems my view (w/ reduce function removed) is still timing out. > > curl: (52) Empty reply from server > > > > real 85m15.699s > > > > I'm not sure what's going on. The map function isn't that complicated. > Any > > ideas on how I could find out what's going on? > > > > Thanks, > > Will > > > > > > On Thu, Sep 11, 2008 at 1:08 AM, Chris Anderson wrote: > > > > > On Wed, Sep 10, 2008 at 7:25 PM, william kinney > > > wrote: > > > > reduce function: > > > > function(keys, values) { > > > > return values; > > > > } > > > > > > > > > > The problem is with your reduce function (and the existing > > > documentation for reduce, which should make this clear, but doesn't). > > > > > > Reduce should only be used to emit scalar values. In your case, you > > > would be better not to define a reduce function at all, and just query > > > the map with startkey and endkey ranges. For example reduce functions, > > > see couch_tests.js's reduce test here: > > > > > > > > > > > > http://svn.apache.org/repos/asf/incubator/couchdb/trunk/share/www/script/couch_tests.js > > > > > > There are also some examples in various blog posts I've written about > > > reduce: > > > > > > Google search for those posts: http://tinyurl.com/couchdb-reduce > > > > > > Hope this helps! > > > > > > Chris > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Chris Anderson > > > http://jchris.mfdz.com > > > > > > ------=_Part_32375_9321502.1221161494552--