Hi Joe, I'm guessing here, but I think the Event Driven scheduling was intended to be more efficient than Timer Driven scheduling, in the way that push notifications should be more efficient than polling. In practice, I'm not sure anyone has measured the difference.
I have seen folks use Event Driven scheduling to get access to the separate thread pool from the Timer Driven pool. For example, if you are running on an 8 core system but you want a Timer Driven pool with 50 threads to do lots of I/O bound tasks, you might create an Event Driven pool with 4 threads and assign your CPU heavy processing to that pool. This limit may avoid having way more than 8 CPU heavy threads (from the Timer Driven pool) bogging down your 8 core system. Regards, -- Mike On Thu, Sep 6, 2018 at 3:11 PM Joe Percivall <[email protected]> wrote: > Hey everyone, > > The dataflow I'm running has one main flow and a couple other disjoint > process groups. Within that main flow, there are sections which aren't used > very often. In trying to optimize things, I looked into the guidance we > have on the "event-driven" scheduling type. There doesn't appear to be much > concrete other than "it's experimental". Which has been the go-to, > basically since being open-sourced. > > So with that, I'm curious about a couple things: > 1: With the recent improvements to the controller and timer-based > scheduling, what should be our guidance on when to use event-based over > timer-based? > 2: Is anyone actually using it in production? > 3: Given it's been 3+ years of "it's experimental", we should start > thinking about either declaring it good to go or deprecating it. > 4: Any lessons learned on optimizing disjoint/sparse flows. > > Cheers, > Joe > -- > *Joe Percivall* > linkedin.com/in/Percivall > e: [email protected] >
