> On Apr 12, 2017, at 1:35 PM, Slagell, Adam J <[email protected]> wrote: > > Justin asked an interesting question today, how does this affect performance > on the manager? That is where we are feeling a lot of pain with select().
If you mean the select() that’s in the process fork’d by the old RemoteSerializer code, you’d still see the same problems with the CAF-based runloop. But that code is irrelevant once Broker takes its place. i.e. to answer that question, you need to design a communication stress test using Broker-based Bros as that’s more relevant than just changing the main loop. Eventually, I can also imagine the Broker-based communication being more tightly integrated into the CAF-based runloop helping improve performance over the current Broker integration method. Either way, what needs to be measured is how CAF’s multiplexer performs in relation to Bro’s communication patterns, but maybe still want to wait for the Broker improvements to wrap up before looking into doing those tests. In the near-term, I can make a totally separate code branch that simply replaces select() with epoll. Then, if Justin were to test it and find it alleviates performance pains on the manager, it could potentially get merged into bro/master ahead of the any of the pending broker/caf/runloop projects since it should be a trivial and safe change to do. Let me know. - Jon _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
