Andrey, Yes, "striped pool" is a thread pool where every thread operate on a single queue. This is the only similarity with FJP, as we do not perform real fork-join in our pools. Having said that, I do not see why we might want to compare our pool with FJP.
As per throughput - it is improved because instead of accessing a single *BlockingQueue *based on *ReentrantLock*, every thread has separate queue. And it is designed in a way, that under load NIO threads usually enqueue tasks and worker threads dequeue tasks without blocking, and even without CAS-loops, thanks to MPSC semantics. Vladimir. On Fri, Dec 16, 2016 at 2:21 PM, Andrey Mashenkov < andrey.mashen...@gmail.com> wrote: > Vladimir, > > As I understand "striped pool" is a array of single-threaded pools. Do you > have an understanding why throughput increased up to 40%? > It looks like it is due to every thread has its own task queue. > > As far as I know, there is ForkJoinPool in JDK, FJP implements > ExecutorService interface, has striped tasks queue, has task-stealing > mechanics. > > Can we run Ignite performance tests b\w using "striped pool" and FJP? > > On Fri, Dec 16, 2016 at 11:17 AM, Vladimir Ozerov <voze...@gridgain.com> > wrote: > > > 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 > > > > > > -- > С уважением, > Машенков Андрей Владимирович > Тел. +7-921-932-61-82 > > Best regards, > Andrey V. Mashenkov > Cerr: +7-921-932-61-82 >
