> is likely to be very poor It‘s indeed not magnificent. As for Cloudant +4...8ms per request, if interpolated from other js-related request latencies in my conditions. About the price of validate_doc_update plus little extra.
> I do suggest we look at Lua though Nice idea. I‘ve tried Lua to tune up flight sim, took ~15 minutes to learn. ermouth 2015-09-29 21:23 GMT+03:00 Robert Newson <[email protected]>: > Performance is likely to be very poor but I'm not blocking it. > > I do suggest we look at Lua though. There's a native Erlang lua > interpreter written by Robert Virding. Lua seems a popular choice in this > space, haproxy 1.6 has lua hooks. > > > On 29 Sep 2015, at 06:06, ermouth <[email protected]> wrote: > > > > Jason, > > > > thought about your message more systematically. > > > > We have a distinct tradeoff (JS-provided flexibility vs performance), it > > exists from the beginning of CouchDB. Now, with cluster, we have chance > to > > reduce JS-related impact. > > > > For prev versions I can hardly imagine more than, say, 1K simultaneous > > highly active users per single instance, when JS is actively used. JS > just > > stalls on validates, updates an so on. And if we dared to have lists > > (especially in awful ACL workarounds), 1K turned to 100-300, even for > thick > > i7. > > > > To increase number of users, to scale, I had to have smth in front of (N > * > > CouchDB). And that ‘smth’ is always quite complex. Moreover, it is always > > task-specific, non-general. > > > > With cluster, the problem goes solved in general, and no additional > ‘smth’ > > in front of CouchDB needed. Got 1001-th user? Add one more node, that‘s > > all. We already have this problem nearly solved, by cluster nature. > > > > So why not to extend – dramatically – CouchDB playground? Shared DBs out > of > > the box is badly desired option, as I see. > > > > And it‘s a very cheap way to make ALL couchappers happy for a long time ) > > > > BR > > > > ermouth >
