On Wed, Jun 13, 2012 at 8:52 AM, Luke Kanies <[email protected]> wrote: > On Jun 12, 2012, at 8:55 PM, Peter Meier <[email protected]> wrote: >> >>>> I'm hoping that 3.0 brings some significant performance >>>> improvements. >>> >>> We discovered some functionality regressions that we are working >>> on right now and hope to have out of the way soon. We've also made >>> the decision to hold off on releasing 3.0 until we have worked on >>> the performance. So for the next month or so the team working on >>> Puppet is going to be trying to improve the performance of 3.0. I >>> would like us to achieve the performance of 2.6, but I don't know >>> if that is going to happen, at the very least I don't want 3.0 to >>> perform any worse than 2.7. >>> >>> What this means is that the already bad state of our pull request >>> queue on github isn't going to get better soon, because in order >>> for us to be able to concentrate on speeding up 3.0 we'll need to >>> divert our attention away from other things for a while. That is >>> the tradeoff that we are going to make, but it won't last forever, >>> and we'll try to get back to getting on top of our pull requests >>> and >> >> I would really appreciate that. I recently moved a larger installation >> to 2.7 (latest) and I'm probably going back, as the slow down + >> extended memory usage is just not worth it. >> >> Compile time doubled in my case (~60s compared to 27s). We migrated >> everything away from global scope variables to class parameters with >> hiera lookups, but I can't imagine that these additional 30s come from >> these lookups only. Especially as we also migrated from full to thin >> stored configs within that migration. >> I can tell more once I downgraded to test my assumption. > > Even 27s is ridiculous. > > Would you be willing to share your configs with us so we can do some > performance analysis on them? Starting with known-slow configs would > make a big difference.
Actually, this is a group where y'all probably *can* deliver on this request: If you are experiencing poor performance, it would be awesome if you could generate some profiling data for us. perftools.rb is the nicest profiler for Ruby I have found, and if y'all could install it, grab a sample of the system while it is being slow, and give us the data that would be awesome. Profiling an agent is pretty easy - just run it. Profiling a master is a little harder, but there is a linked rack profiling hook on the perftools.rb repo, and you can use that to obtain profiling data from the server too. You might want to crank samples per second up to 1,000 from the default 100, and consider wall clock rather than CPU clock profiling. The repository is here: https://github.com/tmm1/perftools.rb Just installing the gem is the easiest way to get this working; that requires compiling C code, so a compiler, and ruby-dev or equivalent. While we can try and reproduce the performance hotspot locally, having data in-situ is a big help too. -- Daniel Pittman ⎋ Puppet Labs Developer – http://puppetlabs.com ♲ Made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
