Vladimir, Got it. "Stripe pool" is really useful stuff for intensive message processing. However, I doubt it is usable for long-life jobs, e.g. SQL queries and some compute jobs without job-stealing feature. Also, having all theads pre-started by default can be an issue.
My point is FJP has no lacks that was disscussed above, and we could check if we get benefits by using FJP in cases when "stripe pool" is seems not to be suitable. Of course we do not need harness that FJP provide for fork-join feature, but some ideas can be adopted. I remember another one, if threads in pool is sleeping and user put a job, FJP has dedicated thread that make waking up other threads. So, pool starts much more faster than any other pool. On Fri, Dec 16, 2016 at 2:39 PM, Vladimir Ozerov <voze...@gridgain.com> wrote: > 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 > > > -- С уважением, Машенков Андрей Владимирович Тел. +7-921-932-61-82 Best regards, Andrey V. Mashenkov Cerr: +7-921-932-61-82
