> This isn’t as clear-cut as you make it sound. To illustrate: This is. 8 cores are still uncommon.
> but outside of db-per-user, a q=1 is usually not a great idea For single-node setup q=8 is also definitely not a great idea. > you usually only speak up here on dev@ > when there is something to pile-on I’m sorry you perceive it in this way. Anyway I kindly ask you to avoid going personal. > 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 I do not think Fauxton is any fixable, otherwise I’d prefer to fix it then to write new admin panel from scratch. In short, the entire UI layout chosen for Fauxton is good when you upfront know what controls you want to place into it, but it isn’t well suited for introducing new features. :From the below post > CouchDB 2.x has and does all of these things. And fails at least order of magnitude more often, requires more RAM (may I say upfront unknown amount of RAM), and has pile of issues at GitHub. > this model is only really suitable for 10s and maybe 100s of concurrent requests I’m sorry to say, but 2.x intermittently drops even non-QS requests of this rate, with no visible pattern. ermouth
