Issue #17190 has been updated by eric sorenson. Assignee changed from eric sorenson to Andrew Parker
I pulled down master and ran some catalogs through it with the profile flag. A couple of questions: * is there a way to enable it from the client (i.e. a command line flag) instead of mock catalog requests w/ manual url? the curl command line ends up like this to get it actually working: <pre> [root@deglitch ssl]# curl -k -H 'Accept: yaml' --cert certs/deglitch.local.pem --key private_keys/deglitch.local 'https://glitched.local:8140/production/catalog/deglitch.local?profile' </pre> ...which is kind of nasty and not repeatable if you're trying to profile your actual nodes * it wasn't clear that the square-bracket timestamp was a unique request id that you could use to trace/grep for related messages. this might just be a documentation thing but it seemed worth noting. * are the numbered steps in the 'outline' form consistent throughout puppet? ie. is 1.1 always node lookup, 1.4 always rendering, etc? If so it would be completely amazing to have an overview (again, probably in documentation) about what those steps are. Generally this is completely wonderful and should really help people get a deeper understanding of what's going on under the hood. ---------------------------------------- Feature #17190: detailed accounting/debugging of catalog compilation times https://projects.puppetlabs.com/issues/17190#change-87600 * Author: Joshua Hoblitt * Status: Merged - Pending Release * Priority: Low * Assignee: Andrew Parker * Category: logging * Target version: 3.2.0 * Affected Puppet version: 2.7.19 * Keywords: * Branch: https://github.com/puppetlabs/puppet/pull/1511 ---------------------------------------- Recently, something has made my catalog compilation times jump up significantly. All fingers are pointing towards this being the fault of new module(s) that are in use. After some discussion on #puppet, it appears there is no intelligent way of diagnosing the code at fault except by removing modules one at a time from the manifests to see which is at fault. So level of introspection on the catalog build process would be very helpful here. It would be really useful to have a master side debugging mode that would dump detailed timing information on the catalog compilation process into the log. Perhaps something that could be enable for just a single agent names or a wildcard match. I imagine tracing the timing to classes would be difficult but perhaps the amount of time spent on each resource would be possible to account for? Ie, if I knew a ton of time was spent processing sshkey resources I'd could fairly quickly trace that back to the module at fault. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
