On Fri, May 11, 2012 at 7:57 AM, CGS <cgsmcml...@gmail.com> wrote: > What I don't understand is the followings: > 1. Those guys wanted a single front-end server which should keep up with > the incoming requests, correct? As far as I understood, CouchDB philosophy > is based on safety of the data, which was implemented as direct writes on > harddisk. So, having only one front-end server on which you force its hdd > to to keep up with the high speed internet connection is just like you want > to force a river to flow only through a mouse hole.
>From my understanding of the post, the core issue wasn't a mismatch in scale between desired throughput (the river) and available throughput (the mousehole), it was that under high enough load CouchDB stopped honoring certain classes of requests entirely. That's not a "too slow" problem, it's a "fell over and can't get up" problem. I think it's very important that effort is made to reproduce and address these issues, since without being able to put more definite bounds on them, *everyone* is going to wonder if their load is high enough to trigger the problems. Heck, I'm wondering it, and I don't typically have more than a couple hundred docs per DB (but a lot of DBs, and hundreds of megs of attachments per DB). Eli
