If you get a profiling suite together (aka, bunch of random patches) could you release it?
I've been curious about this for quite some time but never quite got around to dealing with it. My concern is very much client side performance since the more you managing a client, the less the client gets to do it's actual job. Thanks, Trevor On Mon, Jun 29, 2015 at 4:35 PM, Henrik Lindberg < henrik.lindb...@cloudsmith.com> wrote: > On 2015-29-06 16:48, Romain F. wrote: > >> Hi everyone, >> >> I try to optimize our Puppet runs by running some benchmarks and >> patching the puppet core (if possible). But I have some difficulties >> around the catalog serialization/deserialization. >> >> In fact, in 3.7.5 or 3.8.x, the Config Retrieval takes roughly 7secs and >> only 4 secs is on the master side. Same fact in 4.2 but with 9 secs of >> config retrieval and still 4 secs on the master side. >> >> My first thoughts was "Okay, time to try MsgPack". No improvements. >> >> I've instrumented a bit the code in the master branch around this, and >> I've found out that, on my 9secs of config retrieval, 3.61secs is lost >> in catalog deserialization, 2 secs is the catalog conversion.. But it's >> not the "real" deserialization (PSON to Hash) that takes ages, it's the >> creation of the Catalog object itself (Hash to catalog). Benchmarks >> shows that the time to deserialize MsgPack (or PSON) is negligible >> compared to the catalog deserialization time. >> >> So here is my question : Is that a known issue ? Is there any reason of >> the regression in 4.x (Future parser creating more objects, ...) ? >> >> The parser=future setting only makes a difference when compiling the > catalog - the catalog itself does not contain more or different data > (except possibly using numbers instead of strings for some attributes). > > The best way to optimize this is to write a benchmark using the benchmark > framework and measure the time it takes to deserialize a given catalog. > Then run that benchmark with Ruby profiling turned on. > > There are quite a few things going on at the agent side in addition to > taking the catalog PSON and turning it into a catalog that it can apply > (loading types, resolving providers, etc). Make sure to benchmark these > separately if possible. > > Regards > - henrik > > Cheers, >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Puppet Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send >> an email to puppet-dev+unsubscr...@googlegroups.com >> <mailto:puppet-dev+unsubscr...@googlegroups.com>. >> To view this discussion on the web visit >> >> https://groups.google.com/d/msgid/puppet-dev/a5bf7422-6119-43ee-ba11-44001c1ce097%40googlegroups.com >> < >> https://groups.google.com/d/msgid/puppet-dev/a5bf7422-6119-43ee-ba11-44001c1ce097%40googlegroups.com?utm_medium=email&utm_source=footer >> >. >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > > Visit my Blog "Puppet on the Edge" > http://puppet-on-the-edge.blogspot.se/ > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/mmsa75%24edc%241%40ger.gmane.org > . > > For more options, visit https://groups.google.com/d/optout. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 -- This account not approved for unencrypted proprietary information -- -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoXoa3sShf%2Bs9n4Pn9NJvbhDxJLNEe%3DeyO%2BCdjuvHLoNEg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
