couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chintan Mishra <>
Subject Re: CouchDB and future
Date Tue, 09 Jul 2019 09:00:49 GMT

On 09/07/19 1:21 PM, Jan Lehnardt wrote:
> Hi Ermouth,
>> On 8. Jul 2019, at 21:53, ermouth <> wrote:
>>> disabling clustering (i.e., setting Q=N=1)
>> Let’s start with this one, because it’s about installation process. To set
>> q=1 you should install Couch manually. Built-in installer sets up q=8 for
>> single node setup.
> This isn’t as clear-cut as you make it sound. To illustrate:
> For Mac binaries, I set q=2 by default for the reason that I think I have a
> good understanding of how people use CouchDB on the Mac[1]. I pick 2
> because all Macs today ship with at least a dual core CPU, so we make
> CouchDB a little faster on Macs. But why not q=4 if I detect a four core
> CPU? I also don’t want to be a CPU hog. Mostly Macs are used with
> CouchDB as dev environments, so I know, the CPU will also run an
> editor or IDE, usually some form of middleware, and I don’t want to
> take away CPU time from those.
> [1]:
> * * *
> For non-Mac setups, I don’t feel confident about knowing a q beforehand,
> but outside of db-per-user, a q=1 is usually not a great idea, unless you
> are on a single core machine. All this could be surfaced to the end user
> inside the setup screen on Fauxton, and I know you’re a capable web
> dev, but I haven’t yet seen an improvement suggestion from you towards this.
> FWIW, we already set n=1 dynamically, if only a single node is used, which
> is a lot less controversial, adding a setting for q that is fed by the setup
> wizard doesn’t sound like a whole lot of work:
> * * *
This issue can be resolved by administrative control via HTTP API or 
> I don’t want to discount the constructive participation from you in the past year
> in the GitHub issues, but I’d really love to hear from you at times when we can
> talk about how to fix things, instead, you usually only speak up here on dev@
> when there is something to pile-on, rather than working on having it fixed first.
> Please, let’s get to a mode where we track issues and fix things rather than
> taking things for granted and complain later.
Regarding this we need a better way to communicate. Email and Slack are 
decent but conversations loose context when it is hard to find old 
conversations or how they are related. I would propose 
here again.
> Best
> Jan
> —
>> Compared to Futon, Fauxton is at least uncomfortable. There are two obvious
>> accountable metrics: 1) how many clicks you need to do this or that, 2) how
>> far you need to move mouse to make next click in a logical sequence of
>> actions.
>> Also, as for our experience, protecting Couch admin from administering by
>> hard-disabling write for some _config/*/* endpoints, is a mistake. This
>> kind of role separation isn’t reasonable for single-node scenario (which
>> often is ‘I gonna make something small’).
>> As for stability – unfortunately 2.x bites without notice, patterns are
>> hard to grasp. However, there are at least two: unpredictable RAM
>> footprint, and also unpredictable recoverability after crash. Also 2.x
>> tends to eat disk space slowly (spams in _local docs, sometimes creating
>> strange things like this
>> Best regards,
>> ermouth

View raw message