On 09/07/19 1:21 PM, Jan Lehnardt wrote:
Hi Ermouth,
On 8. Jul 2019, at 21:53, ermouth <ermo...@gmail.com> 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]:
https://github.com/janl/couchdb-mac-app/blob/master/CouchDB%20Server/Apache_CouchDBAppDelegate.m#L185
* * *
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:
https://github.com/apache/couchdb/blob/master/src/setup/src/setup.erl#L186-L188
* * *
This issue can be resolved by administrative control via HTTP API or
environment.
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 spectrum.chat
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 http://ermouth.com/dl/couch_local_doc_dupes.png).
Best regards,
ermouth
