I've already benchmarked and profiled Catalog's from_data_hash and to_data_hash methods using the benchmark framework. Most of the time is spent in the from_data_hash (we already knew it) but there is no big "pitfalls" where Ruby loses his time.
My callgrind file shows that the top 5 (in self time) is : - Array.flatten (55000 calls) - Array.each (115089 calls) - Puppet::Resource.initialize (15000 calls) - String.=~ (65045 calls) - Hash[]= (115084 calls) This top 5 is taking ~30% of the total time . As you can see, it can be dificult to optimize this. IMHO, the "benchmark -> tweak -> benchmark" way of optimizing is not sufficient here. I think the way it (de)serialize a catalog needs a deep refactor. Cheers, Le mardi 30 juin 2015 04:23:42 UTC+2, henrik lindberg a écrit : > > On 2015-29-06 22:41, Trevor Vaughan wrote: > > If you get a profiling suite together (aka, bunch of random patches) > > could you release it? > > > > It is not difficult actually. Look at the benchmarks in the puppet code > base. Many of them are suitable for profiling with a ruby profiler. > I don't think we have any benchmarks targeting the agent side though, so > the first thing to do (for someone) is to write one. > > What is more difficult is coming up with a benchmark that does not > involve real/complex resources - but deserialization and up to actually > applying should be possible to work with in a simple way. > > Profiling is then just running that benchmark with the ruby profiler > turned on and analyzing the result, make changes, run again... (repeat > until happy). > > - henrik > > > > 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 > > <[email protected] <javascript:> <mailto: > [email protected] <javascript:>>> > > wrote: > > > > On 2015-29-06 16 <tel:2015-29-06%2016>: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 [email protected] <javascript:> > > <mailto:puppet-dev%[email protected] <javascript:>> > > > <mailto:[email protected] <javascript:> > > <mailto:puppet-dev%[email protected] <javascript:>>>. > > > 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 [email protected] <javascript:> > > <mailto:puppet-dev%[email protected] <javascript:>>. > > 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 [email protected] <javascript:> > > <mailto:[email protected] <javascript:>>. > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoXoa3sShf%2Bs9n4Pn9NJvbhDxJLNEe%3DeyO%2BCdjuvHLoNEg%40mail.gmail.com > > > < > https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoXoa3sShf%2Bs9n4Pn9NJvbhDxJLNEe%3DeyO%2BCdjuvHLoNEg%40mail.gmail.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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/5f33371f-98e3-429c-8906-8db54b1de717%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
