Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CA+arFLUJqJXEHnWxi6QPw4cENbszraT+6UyoP4b8sH12f7-Nvw@mail.gmail.com>
References: 
 <CA+arFLW2pd8VHFkuP-g8LvrP9im6F9GmqkeHu7sZTUUzVvQ5bQ@mail.gmail.com>
 <CAN-3CBK0rFg02nFPfmdF1+KTHNDhPuz3s0HY6NPFraDXV7vmXw@mail.gmail.com>
 <CA+arFLUJqJXEHnWxi6QPw4cENbszraT+6UyoP4b8sH12f7-Nvw@mail.gmail.com>
From: Jason Smith <jhs@iriscouch.com>
Date: Fri, 23 Mar 2012 11:56:44 +0000
Message-ID: 
 <CAN-3CBJnH-BMT4c=mQjOhTZxLj67XiDGqBBatpDrtt1puYgT4Q@mail.gmail.com>
Subject: Re: Why are reads from CouchDB so slow? (1.5MB/s or thereabouts)
To: user@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8

CouchDB verifies that the document contents match a checksum which
does impose computation and codec overhead, yes.

Considering that CouchDB stores multiple sorted indices to the
documents in a database which is itself a filesystem file, in a safe
append-only format, how would you justify an expectation of static
Nginx performance? Surely CouchDB must open the file (right there you
have tied Nginx at best) and then seek through its metadata to fetch
the doc. Note, my disagreement with you is not fundamental, just of
degree. Surely it is fair to give CouchDB some elbow room to work, to
pay for its benefits?

Back to document comprehension, CouchDB does do that and this is a
huge opportunity for improvement. I believe Filipe has indeed proposed
something much like you describe: store the utf-8 JSON directly on the
disk.

I'm excited that this conversation can paint a more clear picture of
what we expect from CouchDB, to find a speed at which we could say,
"this is slower than Brand X, but it's worth it."

On Fri, Mar 23, 2012 at 11:41 AM, Jonathan Williamson <jon@netcopy.co.uk> wrote:
> As I'm requesting the documents in the exact format I submitted them
> (with no transformations or extra information) I'd expect something
> not far off a static file request from Nginx. As far as I can tell the
> .couch files aren't compressed (though that wouldn't cause such slow
> performance on an i5 anyway) and appear to contain the original
> documents almost "as is".
>
> The other side effect is that while fetching the documents the CPU
> usages rises to 100% which suggests, I guess, that CouchDB is reading,
> deserialising, serialising, and then streaming the document. But it
> doesn't seem like that should be necessary really?
>
> On Fri, Mar 23, 2012 at 11:16 AM, Jason Smith <jhs@iriscouch.com> wrote:
>> Hi, Jonathan.
>>
>> Can we start by identifying how fast you think **is** reasonable. What
>> speeds were you expecting? And on what grounds do you base that
>> expectation?
>>
>> (For example, perhaps connecting and fetching one row from MySQL?)


-- 
Iris Couch