OK, I see what it is doing. The git command score high there. My biggest surprise is a bunch of File resources taking around 0.4 seconds to evaluate; e.g.

info: /File[/root/.bashrc.d/git]: Starting to evaluate the resource
info: /File[/root/.bashrc.d/git]: Evaluated in 0.45 seconds

Any idea why that would be ? That seems really slow for a simple resource!

1) in normal mode, yes. Or rather – I try my best to have a normal run not output *anything* so that I can easily see if something broke during refactoring. However, as you can see from the command, I run it in debug mode for the timing, and in debug mode it’s telling you before it performs an Exec.

2) I know I need to go back to tags and understand better, because it may be a solution for breaking up puppet configs. For now, I’m moving towards making it possible to apply just one module at a time for testing purposes from the command line with puppet apply.

3) When I’m deploying instead of actually changing my puppet config, I’m fine with it taking 30 seconds. It’s when I’m developing new puppet code or refactoring that 30 seconds is simply too long. Another reason why I’ve gone towards setting up virtual machines to test modules in and forcing myself to test modules in isolation before putting them together.

I read your post quickly, but… I have a few comments, and hopefully they will be helpful to you (they’re free anyways):

1) AFAICT, when puppet is running something, it actually prints the output of what it *just* ran, *after* it ran it. I always found this a little stupid, because in some of my puppet scripts I have some very potentially long running ‘exec’s, and I only know which one is taking forever *after* it finishes. So I have to use ps and other tools to debug when needed. This might be useful in case you think one statement is taking timelist[x] seconds when it’s actually taking timelist[x-1]… Right?

2) ‘puppet apply’ has a –tags argument which you can use to specify partial amounts of puppet code to run. I think. I don’t actually use this, although it might be useful, and if you like, feel free to test it out and let me know how it went. Sadly puppet doesn’t have properly working manpages (at least for me) and I think they’ve started keeping it all on their website ever since the license change away from the GPL. (http://docs.puppetlabs.com/man/apply.html) Hopefully I’m wrong about their intentions, because I use and love puppet a lot.

3) Personally when I started using puppet, I was annoyed because my programs would normally compile or just run (eg python) right away! Now I have to sit there for 30 seconds. My solution, I don’t mean this in a rude way, but I got more patient! Now these sorts of things are more appropriate again: http://xkcd.com/303/

Hope this helped!
James

PS: In case it interests you, I’m actually working on puppet code and infrastructure to deploy GNOME and related components. It’s all going to be Free Software when I finish a v0.1 I’ll be writing about it on my blog.

Take a look at the output of using –evaltrace on your puppet runs.

This *should* provide you with all of the information that you need.

Also, if you have a lot of Service objects, they will take quite a bit of time and there’s not much you can do about it. Additionally, I’ve found that Exec and Service *seem* to use the same execution queue and therefore moving your Exec statements to native types can really help your execution time. See the puppetlabs-stdlib code for examples.

Finally, get rid of any recursive File statements working on large directories as they have been shown to be massively inefficient.

Good Luck!

For semanage fcontext, I’ve put up my puppet class here: https://gist.github.com/4628864
Yes, it abuses grep but as you’ve covered, I’ll gladly accept the maintenance burden in exchange for not doing multiple 5-second-per-context-checks.