Yes, this does make sense. Mystery solved I suppose.
But, in that case, couldn't you skip that last phase if you just pass YAML the whole way and cut off a third of the load time? Trevor On Mon, May 14, 2012 at 5:22 PM, Nick Lewis <n...@puppetlabs.com> wrote: > On Monday, May 14, 2012 at 2:19 PM, Trevor Vaughan wrote: > > Any suggestions on where to benchmark here? I tried to figure out > where to hit it but didn't really get anywhere with it. > > I did try using pure ruby to load the catalog from disk using the > Puppet methods and it took 7 seconds in a case where Config retrieval > is reporting around 40 seconds. > > The catalog is being serialized or deserialized three times: once to PSON on > the master to transfer to the agent, once from PSON to revive on the agent, > and once to YAML for the agent to cache it. That seems like it basically > ought to account for the extra time, if one deserialize was 7 seconds. > > Thanks, > > Trevor > > On Mon, May 14, 2012 at 8:09 AM, Brice Figureau > <brice-pup...@daysofwonder.com> wrote: > > On Fri, 2012-05-11 at 20:16 -0400, Trevor Vaughan wrote: > > For another point of data, I tried a handful of different ciphers > between the server and client with no noticeable difference in time. > > > I think (but might be totally wrong) that since you're not seeing any > real improvement with Nick's patch, and you also don't gain much by > disabling caching altogether, then what might take time for you is the > pson deserialization or catalog conversion. Both will create numerous > objects, which is known to be quite expensive. > > I suggest you time (with the Puppet::Util.benchmark method for instance) > the various parts of the Configurer and report us the details. > > Hope tha thelps, > -- > Brice Figureau > Follow the latest Puppet Community evolutions on www.planetpuppet.org! > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To post to this group, send email to puppet-dev@googlegroups.com. > To unsubscribe from this group, send email to > puppet-dev+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-dev?hl=en. > > > > > -- > Trevor Vaughan > Vice President, Onyx Point, Inc > (410) 541-6699 > tvaug...@onyxpoint.com > > -- This account not approved for unencrypted proprietary information -- > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To post to this group, send email to puppet-dev@googlegroups.com. > To unsubscribe from this group, send email to > puppet-dev+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-dev?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To post to this group, send email to puppet-dev@googlegroups.com. > To unsubscribe from this group, send email to > puppet-dev+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-dev?hl=en. -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.