Pulling this sentence out from much earlier in the thread;

"N should be set to the number of nodes."

That's not true and our docs should not say it today or be changed to say it in 
the future.

N is how many copies of a document we'll maintain. If you had a 20 node 
cluster, you would not want 20 copies of every document. The default of 3 
copies would be sufficient to prevent accidental loss.

B.

> On 4 Oct 2019, at 23:55, Joan Touzet <woh...@apache.org> wrote:
> 
> Thanks for the follow-up. Thinking of >1 active DB per host makes this
> calculation a lot more challenging.
> 
> Sounds like our recently merged default change of q=2 will be fine.
> 
> -Joan
> 
> 
> On 2019-10-04 17:40, ermouth wrote:
>> This tuned out to be interesting, results vary heavily for different
>> platforms.
>> 
>> I included `perftest.html` into Photon design doc. The utility gives good
>> insight how q,n impact doc creation, doc update, validate + update, and
>> viewindex create/update – for a particular CouchDB instance.
>> 
>> Common observations:
>> * q=1 is only ok for rare special cases (like DBs with dozen docs)
>> * it’s ok to have q==cores or q==cores+1 or even cores+2: write perf drops
>> a little, but viewindex update is bit faster
>> * excessive q (say, more than cores×2) negatively impacts direct write
>> perf: having q8 for 2core at least halves write perf for most
>> commodity/lean platforms and hw cfg.
>> 
>> ermouth
>> 
>> 
>> чт, 11 июл. 2019 г. в 18:17, Joan Touzet <woh...@apache.org>:
>> 
>>> On 2019-07-11 8:05, ermouth wrote:
>>>>> to help with the documentation step
>>>> 
>>>> Probably. Please give me a hint what you need.
>>> 
>>> What default settings right now are wrong for a system with low RAM, low
>>> CPU, and slow disk - such as a RaspberryPi v1, or a $15/mo AWS server?
>>> 
>>> -Joan
>>> 
>>> 
>> 
> 

Reply via email to