<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 12, 2018 at 8:21 AM Jon Siwek <<a href="mailto:jsiwek@corelight.com">jsiwek@corelight.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
An idea in this type of situation could be to tune Broker::max_threads<br>
per node type. E.g. leave at 1 for workers and bump to ~4 for<br>
manager/logger since there's idle cores on their host and they're<br>
inherently in a less-scalable/centralized location. </blockquote><div><br></div><div>For those that haven't yet dug into all that is Broker, this brings up a question on the general architecture. Are there still parent/child processes handling comms/work? I'd assume the fork is gone, so the new code is dropping a process but gaining a thread, in essence a wash. </div><div><br></div><div>Is there a mechanism today for per node type tuneables?</div><div><br></div><div> ...alan</div></div></div>