Folks, Can we move all discussions aside of pool config to separate threads, please? :-)
Dima, I heard your concern about configuration complexity. But I do not see any problem at all. Whether to use striped pool or not is a matter of fine-grained tuning. We will set sensible defaults (i.e. enabled striped pool), so 99% of users will never know that a concept of "stiped pool" even exists. Striped and non-striped approaches have their own pros and cons. Striped: + Better overall throughput (up to +40% compared to non-striped); - Less predictable latency - user can have bad numbers even on moderate load (e.g. consider updates on a large affinity co-located object graph). Benchmarks demonstrate this clearly. - Higher memory footprint, because in striped mode we pre-start all the threads. On high-end machines it may end up in wasting of hundrends of megabytes of RAM. - As a result of previous point, it is not well-suited for clients, which may require small memory footprint and low startup time. Non-striped: - Worse throughput due to very high contention on BlockingQueue. + No waste on idle threads. I would propose the following final design for this: - Introduce *"boolean systemThreadPoolStriped"* property; - Set it to *"true"* for servers by default; - Set it to *"false"* for clients by default. Yakov, I still do not get your point about (system + public) pools approach. Vladimir. On Fri, Dec 16, 2016 at 9:29 AM, Yakov Zhdanov <yzhda...@apache.org> wrote: > >In my view, we should hide most of such configuration intricacies from > users, > and select an appropriate thread pool for each task ourselves. Will this be > possible? > > We already do this. We take decision internally on where to route the > request. > > SoE, my answers below. > > >How did the striped pool show itself for transactional updates that > involve 2 phase commit? Any benefits or degradation? > > Even better than for atomic - up to ~50% improvement. > > >Here we should decide what’s more important for us - throughout or > latency. If to execute SQL queries in the striped pool using multiple > partitioned threads then, for sure, it will affect latency of other > operations that are sitting in the queue waiting for their time to be > processed but, on the other hand, the overall throughput of the platform > should be improved because the operations will be less halted all the time > by synchronization needs. > > >VoltDB decided to go for with the throughput while our current > architecture is mostly latency based. > > What do you mean by "using several partition threads"? I am pretty sure > that if we do as you suggest we will have degradation here instead of > boost: > > sql-query-put > after: 77,344.83 > before: 53,578.78 > delta: 30.73% > > sql-query-put-offheap > after 32,212.30 > before 25,322.43 > delta 21.39% > > --Yakov
