couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: CouchDB and future
Date Tue, 09 Jul 2019 07:51:05 GMT
Hi Ermouth,

> On 8. Jul 2019, at 21:53, ermouth <ermouth@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

* * *

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.

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


Mime
View raw message