On Mon, Feb 17, 2014 at 6:20 AM, jcbollinger <john.bollin...@stjude.org> wrote:
> Well, I think the question that killed this thread the first time boils down > to "would it really?". The speculation at the time was that parallel > execution would produce disappointing wall-time gains, based on the > assertion that the catalog application process is largely I/O bound. There > were also some assertions that Ruby doesn't do shared-memory parallelism > very well. Nobody reported any actual analysis of any of that, though. Right. Without such analysis it's hard to know if this idea is worth following up on today. But, one thing to keep in mind is that systems are always changing. An I/O bound system of today might not be I/O bound tomorrow as technological improvements appear. Having a computer with available resources unable to apply to resources to a Puppet run (or anything else) is wasteful. In time, the lack of client parallelization could be a competitive weakness as Puppet competes in the marketplace. (I don't know what the status of client parallelization is in the competition right now). Jon Forrest -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAF0Z9ipsPHh%2BZOC_VJM2x_74ToCD-u-imyk4Y9bXyi4wxMhYtg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
