Puppet users - Feb 2010 - Magazine article comparing CPU usage of Puppet vs. Cfengine

I received my copy of ;login (the Usenix magazine) today. There''s an
article* comparing CPU utilisation of Puppet and Cfengine. To
abbreviate massively: Puppet requires much more CPU than Cfengine when
both verifying and fixing configuration.

I''m in the early days of implementing Puppet and this has given me
something to think about. Whilst I won''t be verifying/fixing
configuration on our servers on a continual basis, it would be nice if
it could be done with low CPU overhead. I am not familiar with
Cfengine beyond the reading I did while choosing which configuration
management tool to use; I chose Puppet because it seemed more flexible
and I figured me and my team would be able to get more done in less
time once we''d learned how to use it.

Can CPU overhead be reduced to something closer to Cfengine, or is it
inherent in the design/implementation of Puppet? Is there an upside in
terms of greater flexibility of Puppet?

I''d welcome comments from those familiar with both Puppet and Cfengine.

*Article is here:
http://www.usenix.org/publications/login/2010-02/pdfs/bjorgeengen.pdf.
Note that reading the magazine article requires a subscription, at
least until Feb 2011 (articles published more than 12 months ago are
openly available).

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Mon, 22 Feb 2010 21:17:52 +0000, Toby Riddell <toby.riddell@gmail.com>
wrote:
> I received my copy of ;login (the Usenix magazine) today. There''s
an
> article* comparing CPU utilisation of Puppet and Cfengine. To
> abbreviate massively: Puppet requires much more CPU than Cfengine when
> both verifying and fixing configuration.
> 
> I''m in the early days of implementing Puppet and this has given me
> something to think about. Whilst I won''t be verifying/fixing
> configuration on our servers on a continual basis, it would be nice if
> it could be done with low CPU overhead. I am not familiar with
> Cfengine beyond the reading I did while choosing which configuration
> management tool to use; I chose Puppet because it seemed more flexible
> and I figured me and my team would be able to get more done in less
> time once we''d learned how to use it.
> 
> Can CPU overhead be reduced to something closer to Cfengine, or is it
> inherent in the design/implementation of Puppet? Is there an upside in
> terms of greater flexibility of Puppet?
> 
> I''d welcome comments from those familiar with both Puppet and
Cfengine.
> 
> *Article is here:
> http://www.usenix.org/publications/login/2010-02/pdfs/bjorgeengen.pdf.
> Note that reading the magazine article requires a subscription, at
> least until Feb 2011 (articles published more than 12 months ago are
> openly available).
I''m not really surprised by this, puppet is written in Ruby (an
interpreted
language) vs CFengine which is written in C.  I''ve used both, and
I''d
gladly trade a little CPU performance for the stability gains offered by
puppet.  CFengine is notoriously buggy in implementation, something I can
definitely attest to (like when spaces make a difference in
unions/intersections when the documentation plainly says they should
not...).

I''d have to see the article to know for sure if the CPU utilization
difference is negligible, but having run puppet for several months now I
have not seen any performance impact myself.  Most systems have so may
extra cores nowadays that aren''t doing anything (especially in our
case,
running puppet during off-hours) it would have to peg multiple CPUs for an
extended period of time to make a noticeable impact.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

>
> I''m not really surprised by this, puppet is written in Ruby (an
interpreted
> language) vs CFengine which is written in C.  I''ve used both, and
I''d
> gladly trade a little CPU performance for the stability gains offered by
> puppet.  CFengine is notoriously buggy in implementation, something I can
> definitely attest to (like when spaces make a difference in
> unions/intersections when the documentation plainly says they should
> not...).
>
> I''ve used CfEngine 2, and would gladly trade CPU utilisation for
the more
expressive DSL.  Swapping the order of operations round in the
actionsequence  declaration got boring, too.  (not sure about version 3).

J.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 22 February 2010 16:37, James Cammarata <jimi@sngx.net>
wrote:
>
> On Mon, 22 Feb 2010 21:17:52 +0000, Toby Riddell
<toby.riddell@gmail.com>
> wrote:
>> I received my copy of ;login (the Usenix magazine) today.
There''s an
>> article* comparing CPU utilisation of Puppet and Cfengine. To
>> abbreviate massively: Puppet requires much more CPU than Cfengine when
>> both verifying and fixing configuration.
>>
>> I''m in the early days of implementing Puppet and this has
given me
>> something to think about. Whilst I won''t be verifying/fixing
>> configuration on our servers on a continual basis, it would be nice if
>> it could be done with low CPU overhead. I am not familiar with
>> Cfengine beyond the reading I did while choosing which configuration
>> management tool to use; I chose Puppet because it seemed more flexible
>> and I figured me and my team would be able to get more done in less
>> time once we''d learned how to use it.
>>
>> Can CPU overhead be reduced to something closer to Cfengine, or is it
>> inherent in the design/implementation of Puppet? Is there an upside in
>> terms of greater flexibility of Puppet?
>>
>> I''d welcome comments from those familiar with both Puppet and
Cfengine.
>>
>> *Article is here:
>> http://www.usenix.org/publications/login/2010-02/pdfs/bjorgeengen.pdf.
>> Note that reading the magazine article requires a subscription, at
>> least until Feb 2011 (articles published more than 12 months ago are
>> openly available).
>
> I''m not really surprised by this, puppet is written in Ruby (an
interpreted
> language) vs CFengine which is written in C.  I''ve used both, and
I''d
> gladly trade a little CPU performance for the stability gains offered by
> puppet.  CFengine is notoriously buggy in implementation, something I can
> definitely attest to (like when spaces make a difference in
> unions/intersections when the documentation plainly says they should
> not...).
>
Comparing CPU utilisation is like benchmarking cars by seeing how well
they float.

CPU utilisation can be solved by throwing hardware at the problem.
Expressiveness and stability can''t be solved through hardware.

Lindsay


-- 
w: http://holmwood.id.au/~lindsay/
t: @auxesis

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Feb 22, 1:17 pm, Toby Riddell <toby.ridd...@gmail.com>
wrote:
> I received my copy of ;login (the Usenix magazine) today. There''s
an
> article* comparing CPU utilisation of Puppet and Cfengine. To
> abbreviate massively: Puppet requires much more CPU than Cfengine when
> both verifying and fixing configuration.
I had major CPU and RAM trouble back when I was using puppet to copy
big binary files.  I switched to deploying them using a custom apt
server, and most of my problems went away.  I''ve also had trouble with
clients that have a high latency to the server in 0.24.x, but I''ve
heard that''s fixed in 0.25.x.
-Patrick Mohr

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

> Comparing CPU utilisation is like benchmarking cars by seeing how well
> they float.
Without wanting to appear flippant, perhaps I want a floating car :)

In my case I need a tool that *if* run during production hours will
consume very little CPU - we''ve got very stringent requirements for
application jitter. It''s likely we''ll end up running Puppet
(or
whatever) only outside production hours.

 (We may end up setting up dedicated processor sets for the
applications, leaving a pool for other processes, including Puppet -
clearly configuring processor sets is something that Puppet can help
with!)

Toby

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

> I''d have to see the article to know for sure if the CPU
utilization
> difference is negligible, but having run puppet for several months now I
> have not seen any performance impact myself.  Most systems have so may
> extra cores nowadays that aren''t doing anything (especially in our
case,
> running puppet during off-hours) it would have to peg multiple CPUs for an
> extended period of time to make a noticeable impact.
From the results in the article, Puppet required between 10x and 56x
more CPU seconds.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Am Tuesday 23 February 2010 schrieb mir tobyriddell:
> > Comparing CPU utilisation is like benchmarking cars by seeing how
> > well they float.
> 
> Without wanting to appear flippant, perhaps I want a floating car :)
> 
> In my case I need a tool that *if* run during production hours will
> consume very little CPU - we''ve got very stringent requirements
for
> application jitter. It''s likely we''ll end up running
Puppet (or
> whatever) only outside production hours.
Do you know process priorities? It''s very easy to run puppet with this.
Most CPUs has so much idle times that puppet is not a problem. The RAM 
usage could be a more significant problem in smaller systems.

Regards
Oli

On Tue, Feb 23, 2010 at 11:11 AM, Oliver Schad <puppet@oschad.de>
wrote:
>
>
> Do you know process priorities? It''s very easy to run puppet with
this.
> Most CPUs has so much idle times that puppet is not a problem. The RAM
> usage could be a more significant problem in smaller systems.
>
Using nice is not an option with puppet, as all services/daemons that puppet
will start would be in the same nice level as puppet.

Ohad

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Hello

When testing puppet scalability, we noticed that one bottleneck is CPU usage on
puppetmaster node.
To scale up the number of concurrent puppet clients running in the same time, we
tweaked our puppet configuration in
order to reduce puppetmaster work, mainly reducing its CPU work, and so scale
up. (One major point was: do not overload
your fileserver).


Aurélien

Toby Riddell a écrit :
> I received my copy of ;login (the Usenix magazine) today. There''s
an
> article* comparing CPU utilisation of Puppet and Cfengine. To
> abbreviate massively: Puppet requires much more CPU than Cfengine when
> both verifying and fixing configuration.
> 
> I''m in the early days of implementing Puppet and this has given me
> something to think about. Whilst I won''t be verifying/fixing
> configuration on our servers on a continual basis, it would be nice if
> it could be done with low CPU overhead. I am not familiar with
> Cfengine beyond the reading I did while choosing which configuration
> management tool to use; I chose Puppet because it seemed more flexible
> and I figured me and my team would be able to get more done in less
> time once we''d learned how to use it.
> 
> Can CPU overhead be reduced to something closer to Cfengine, or is it
> inherent in the design/implementation of Puppet? Is there an upside in
> terms of greater flexibility of Puppet?
> 
> I''d welcome comments from those familiar with both Puppet and
Cfengine.
> 
> *Article is here:
> http://www.usenix.org/publications/login/2010-02/pdfs/bjorgeengen.pdf.
> Note that reading the magazine article requires a subscription, at
> least until Feb 2011 (articles published more than 12 months ago are
> openly available).
> 

-- 
Aurelien Degremont
CEA

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 23 February 2010 03:49, tobyriddell <toby.riddell@gmail.com>
wrote:
>> Comparing CPU utilisation is like benchmarking cars by seeing how well
>> they float.
>
> Without wanting to appear flippant, perhaps I want a floating car :)
Then perhaps you should be looking for a boat?

Puppet''s performance and scaling problems aren''t that unique.
It''s
pretty much the same thing that happened with Rails - people started
using and deploying it without considering the performance
implications, and were surprised when it didn''t scale. Rails *does*
scale, just not out of the box. I''d wager that, to a certain extent,
Puppet is in the same boat.

Performance, expressiveness, stability. Pick two.
>
> In my case I need a tool that *if* run during production hours will
> consume very little CPU - we''ve got very stringent requirements
for
> application jitter. It''s likely we''ll end up running
Puppet (or
> whatever) only outside production hours.
>
>  (We may end up setting up dedicated processor sets for the
> applications, leaving a pool for other processes, including Puppet -
> clearly configuring processor sets is something that Puppet can help
> with!)
>
> Toby
>
> --
> You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
>
>


-- 
w: http://holmwood.id.au/~lindsay/
t: @auxesis

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 23 feb, 10:02, tobyriddell <toby.ridd...@gmail.com>
wrote:
> From the results in the article, Puppet required between 10x and 56x
> more CPU seconds.
Out of curiosity, which part of puppet is causing this load? If it''s
the puppetmaster, well then, that shouldn''t be a big problem.
I''d
recommend a dedicated puppetmaster in most setups anyway. Or when
puppet is actually applying a whole manifest instead of just checking
if things are set correctly? I''ve looked at our trending and I
don''t
see any noticeable additional load on the machines, at least. Unless
of course I''m rebuilding the entire server. But I don''t care
about
puppet load at such times. A little nuance for us non-subscribers to
Usenix would be welcome :)

--
Kind regards,
Tim

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Tue, 23 Feb 2010 08:57:37 -0800 (PST), Tim Stoop <tim.stoop@gmail.com>
wrote:
> On 23 feb, 10:02, tobyriddell <toby.ridd...@gmail.com> wrote:
>> From the results in the article, Puppet required between 10x and 56x
>> more CPU seconds.
> 
> Out of curiosity, which part of puppet is causing this load? If
it''s
> the puppetmaster, well then, that shouldn''t be a big problem.
I''d
> recommend a dedicated puppetmaster in most setups anyway. Or when
> puppet is actually applying a whole manifest instead of just checking
> if things are set correctly? I''ve looked at our trending and I
don''t
> see any noticeable additional load on the machines, at least. Unless
> of course I''m rebuilding the entire server. But I don''t
care about
> puppet load at such times. A little nuance for us non-subscribers to
> Usenix would be welcome :)
Also, this doesn''t seem to be CPU load, just time.  It took puppet
longer
to apply a manifest than CFengine, I''m assuming they made the same
changes
on both systems and had both CFengine and puppet correct the same
differences.  Wall clocks != higher load.

In my opinion, this is a non-issue, since normally if you''ve got any
major
number of systems you''ll either be triggering runs in parallel, or
they''ll
be updating automatically on their own environment wide.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

> Out of curiosity, which part of puppet is causing this load? If
it''s
> the puppetmaster, well then, that shouldn''t be a big problem.
I''d
> recommend a dedicated puppetmaster in most setups anyway. Or when
> puppet is actually applying a whole manifest instead of just checking
> if things are set correctly? I''ve looked at our trending and I
don''t
> see any noticeable additional load on the machines, at least. Unless
> of course I''m rebuilding the entire server. But I don''t
care about
> puppet load at such times.
> A little nuance for us non-subscribers to Usenix would be welcome :)
Apologies - should have given some more details (I''ll respect
Usenix''s
copyright so won''t cut/paste wholesale)

The measured CPU was puppetd on the client, the command run was: /usr/
sbin/puppetd --no-daemonize --onetime

The result was either to add entries to /etc/hosts or to confirm the
contents of /etc/hosts.

Toby

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

> Also, this doesn''t seem to be CPU load, just time.  It took puppet
longer
> to apply a manifest than CFengine, I''m assuming they made the same
changes
> on both systems and had both CFengine and puppet correct the same
> differences.  Wall clocks != higher load.
The difference was found to be in CPU seconds, ''force cswitch''
(i.e.
CPU time quantum used up) was also measured and the ratios found were
similar.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

James Cammarata wrote:
> Also, this doesn''t seem to be CPU load, just time.  It took puppet
longer
> to apply a manifest than CFengine, I''m assuming they made the same
changes
> on both systems and had both CFengine and puppet correct the same
> differences.  Wall clocks != higher load.
> 
> In my opinion, this is a non-issue, since normally if you''ve got
any major
> number of systems you''ll either be triggering runs in parallel, or
they''ll
> be updating automatically on their own environment wide.
The time it takes to run Puppet is an issue to me.  I have some
machines where it takes 30 seconds for ''puppetd --onetime'' to
complete, even when there is nothing to do.  That''s annoyingly
long to wait when I have written a new class and am testing the
new manifests.  Only to find out that nothing happened, realize
I forgot to actually call include on the new class, and then
there''s another half minute wait.

This is on pretty recent eight-core Opteron machines with
32 Gbyte RAM and sitting mostly idle.  It does include
plugin-syncing, though.

On the other hand, some other machines take just 10-11 seconds
to complete, even though there are more resource declarations
for them in the manifests.  It''s not obvious why some machines
take longer to run Puppet than others, and I haven''t had time
to investigate in more detail what causes that.  I''ll have to
do that some day.

If the unattended runs (which I do every fourth hour from cron)
takes five or fifty seconds doesn''t matter much to me, but the
wait during interactive development of the manifests is irritating.


	/Bellman

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Just out of curiosity, do the ones that take longer happen to be 64 bit?

Also, does using --tags do what you want in terms of testing speed?

Trevor

On Tue, Feb 23, 2010 at 3:43 PM, Thomas Bellman <bellman@nsc.liu.se>
wrote:
> James Cammarata wrote:
>
>> Also, this doesn''t seem to be CPU load, just time.  It took
puppet longer
>> to apply a manifest than CFengine, I''m assuming they made the
same changes
>> on both systems and had both CFengine and puppet correct the same
>> differences.  Wall clocks != higher load.
>>
>> In my opinion, this is a non-issue, since normally if you''ve
got any major
>> number of systems you''ll either be triggering runs in
parallel, or they''ll
>> be updating automatically on their own environment wide.
>
> The time it takes to run Puppet is an issue to me.  I have some
> machines where it takes 30 seconds for ''puppetd
--onetime'' to
> complete, even when there is nothing to do.  That''s annoyingly
> long to wait when I have written a new class and am testing the
> new manifests.  Only to find out that nothing happened, realize
> I forgot to actually call include on the new class, and then
> there''s another half minute wait.
>
> This is on pretty recent eight-core Opteron machines with
> 32 Gbyte RAM and sitting mostly idle.  It does include
> plugin-syncing, though.
>
> On the other hand, some other machines take just 10-11 seconds
> to complete, even though there are more resource declarations
> for them in the manifests.  It''s not obvious why some machines
> take longer to run Puppet than others, and I haven''t had time
> to investigate in more detail what causes that.  I''ll have to
> do that some day.
>
> If the unattended runs (which I do every fourth hour from cron)
> takes five or fifty seconds doesn''t matter much to me, but the
> wait during interactive development of the manifests is irritating.
>
>
>        /Bellman
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>


-- 
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaughan@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Tue, Feb 23, 2010 at 12:58 PM, tobyriddell <toby.riddell@gmail.com>
wrote:
> The result was either to add entries to /etc/hosts or to confirm the
> contents of /etc/hosts.
I haven''t read the article, but from this piece of information
I''m
_highly_ skeptical of the results having much to do with puppet
itself.

I very much doubt that anyone with any credibility will state puppet
uses less CPU time than cfengine for similar tasks, but the authors
appear to have specifically selected an editfiles task which cfengine
does quite well and puppet does not have the native ability to manage.
 (Unless it''s been added in recent releases...)

For reference:
"The hardest code to transition will be editfiles code, since Puppet
does not and probably never will provide an analogous feature.
Instead, you will need to use something like external templates or
create custom Puppet types."
From http://reductivelabs.com/trac/puppet/wiki/TransitioningFromCfengine

If the author specifically focused on managing file contents like
entries in /etc/hosts, then puppetd CPU time will be a reflection of
how the author extended puppet to edit files.  Perhaps they just did
thousands of sed executions, or perhaps they wrote their own custom
type or leveraged the flexibility of templates.  Perhaps they used
augeas, which is specifically designed for this sort of thing.

It sounds like it would have been more apt for the paper to present
the experience the author went through to extend puppet to have
editfiles functionality.  I would be interested in a paper discussing
how cfengine may be extended to support some of the more useful
features of puppet.

-Jeff McCune

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

..or perhaps they used the native hosts type that exists to manage
/etc/hosts entries?

On Tue, Feb 23, 2010 at 5:55 PM, Jeff McCune <mccune.jeff@gmail.com>
wrote:
> On Tue, Feb 23, 2010 at 12:58 PM, tobyriddell
<toby.riddell@gmail.com>
> wrote:
> > The result was either to add entries to /etc/hosts or to confirm the
> > contents of /etc/hosts.
>
> I haven''t read the article, but from this piece of information
I''m
> _highly_ skeptical of the results having much to do with puppet
> itself.
>
> I very much doubt that anyone with any credibility will state puppet
> uses less CPU time than cfengine for similar tasks, but the authors
> appear to have specifically selected an editfiles task which cfengine
> does quite well and puppet does not have the native ability to manage.
>  (Unless it''s been added in recent releases...)
>
> For reference:
> "The hardest code to transition will be editfiles code, since Puppet
> does not and probably never will provide an analogous feature.
> Instead, you will need to use something like external templates or
> create custom Puppet types."
> From http://reductivelabs.com/trac/puppet/wiki/TransitioningFromCfengine
>
> If the author specifically focused on managing file contents like
> entries in /etc/hosts, then puppetd CPU time will be a reflection of
> how the author extended puppet to edit files.  Perhaps they just did
> thousands of sed executions, or perhaps they wrote their own custom
> type or leveraged the flexibility of templates.  Perhaps they used
> augeas, which is specifically designed for this sort of thing.
>
> It sounds like it would have been more apt for the paper to present
> the experience the author went through to extend puppet to have
> editfiles functionality.  I would be interested in a paper discussing
> how cfengine may be extended to support some of the more useful
> features of puppet.
>
> -Jeff McCune
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
>
puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Trevor Vaughan top-posted:
> Just out of curiosity, do the ones that take longer happen to be 64 bit?
Well, yes, they are indeed 64 bit (x86_64).  But that doesn''t
distinguish them from the quicker ones.  They are all running
CentOS 5.4 for x86_64, and they all have identical quad-core
Opteron CPUs and identical motherboards, RAID controllers, and
disks.

There are differences though; some machines have dual processors
(i.e. 8 cores) with 32 Gbyte RAM and run Xen, while some have
single processors with 16 Gbyte RAM and do not run Xen.  I haven''t
seen any *obvious* correlation between speed and non-Xen, dom0 or
domU, or with amount of virtual CPU:s or RAM assigned to the
domains, but as I said I haven''t really had time to analyze the
problem properly.
> Also, does using --tags do what you want in terms of testing speed?
It does speed things up, yes.  I have tried to use it, but:

- You need to list all classes you have changed.  Easy if you
   have only touched one class, but sometimes changes affect
   multiple classes.  (They might all be included from some
   common class, but then you need to look up the name of that
   class.)

- When you use inheritance, it seems that you need to list the
   base class, not the class you actually include().

- I want to make a final test run with the entire configuration
   anyway, so I know I haven''t broken something I didn''t
intend.
   If I don''t use --tags I get that for free.

- The speedup isn''t really that great.  It helps, but it only
   takes a slow node from 30 seconds to 20 seconds, or a quicker
   node from 15 to 10 seconds.

Altogether it means that remembering to use --tags is barely
worth it.


-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Tue, Feb 23, 2010 at 6:23 PM, Disconnect <dc.disconnect@gmail.com>
wrote:
> ..or perhaps they used the native hosts type that exists to manage
> /etc/hosts entries?
Dooh, thank you.  I wish I could remove the previous email to prevent
my own misunderstanding from spreading.  I should go read the paper.
> On Tue, Feb 23, 2010 at 5:55 PM, Jeff McCune <mccune.jeff@gmail.com>
wrote:
>>
>> On Tue, Feb 23, 2010 at 12:58 PM, tobyriddell
<toby.riddell@gmail.com>
>> wrote:
>> > The result was either to add entries to /etc/hosts or to confirm
the
>> > contents of /etc/hosts.
>>
>> I haven''t read the article, but from this piece of information
I''m
>> _highly_ skeptical of the results having much to do with puppet
>> itself.
>>
>> I very much doubt that anyone with any credibility will state puppet
>> uses less CPU time than cfengine for similar tasks, but the authors
>> appear to have specifically selected an editfiles task which cfengine
>> does quite well and puppet does not have the native ability to manage.
>>  (Unless it''s been added in recent releases...)
>>
>> For reference:
>> "The hardest code to transition will be editfiles code, since
Puppet
>> does not and probably never will provide an analogous feature.
>> Instead, you will need to use something like external templates or
>> create custom Puppet types."
>> From
http://reductivelabs.com/trac/puppet/wiki/TransitioningFromCfengine
>>
>> If the author specifically focused on managing file contents like
>> entries in /etc/hosts, then puppetd CPU time will be a reflection of
>> how the author extended puppet to edit files.  Perhaps they just did
>> thousands of sed executions, or perhaps they wrote their own custom
>> type or leveraged the flexibility of templates.  Perhaps they used
>> augeas, which is specifically designed for this sort of thing.
>>
>> It sounds like it would have been more apt for the paper to present
>> the experience the author went through to extend puppet to have
>> editfiles functionality.  I would be interested in a paper discussing
>> how cfengine may be extended to support some of the more useful
>> features of puppet.
>>
>> -Jeff McCune
>>
>> --
>> You received this message because you are subscribed to the Google
Groups
>> "Puppet Users" group.
>> To post to this group, send email to puppet-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> puppet-users+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/puppet-users?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Monday 22 February 2010 16:17:52 Toby Riddell wrote:
> I received my copy of ;login (the Usenix magazine) today. There''s
an
> article* comparing CPU utilisation of Puppet and Cfengine. To
> abbreviate massively: Puppet requires much more CPU than Cfengine when
> both verifying and fixing configuration.
>
> *Article is here:
> http://www.usenix.org/publications/login/2010-02/pdfs/bjorgeengen.pdf.
> Note that reading the magazine article requires a subscription, at
> least until Feb 2011 (articles published more than 12 months ago are
> openly available).
>
I have this issue of the magazine as well. The system he used for testing is

an AMD Athlon XP2200, with 1GB RAM running on CentOS5.2 (kernel
2.6.18-92.1.22.el.i686)

The version of CFEngine he is running is 3.0.1b3
(released ??? Jan or Feb ''09, sometime, maybe?)

The version of Puppet he is running is 0.24.7
(released 16-Dec-2008)

So, even though this article was just released, I think it was written a
year
ago. The author said these were the latest stable versions at the time of
writing.

Regards,
Andrew

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23/02/10 8:23 PM, Andrew Heagle wrote:
> The version of CFEngine he is running is 3.0.1b3
> (released ??? Jan or Feb ''09, sometime, maybe?)
> 
> The version of Puppet he is running is 0.24.7
> (released 16-Dec-2008)
It''s also important to note the world has moved a LOT since 0.24.7.
 The 0.25.x releases have considerable performance uplift in them IMHO.

Regards

James Turnbull

- -- 
Author of:
* Pro Linux System Administration (http://tinyurl.com/linuxadmin)
* Pulling Strings with Puppet (http://tinyurl.com/pupbook)
* Pro Nagios 2.0 (http://tinyurl.com/pronagios)
* Hardening Linux (http://tinyurl.com/hardeninglinux)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEVAwUBS4S4qiFa/lDkFHAyAQKidwf+K0L68Rc6mGjTS3MENltp0udHsh+/4o8R
uTQ2XS+Vn2mHZpM1wZTFTIZJYin2grOuYF9IiCXiDG8qvc7HM8dFF8a/09gg180c
lPjhleWz2+foN1cUHAPexGO8rvfVukfh62bmB9YoNHztAdT0vKV3zXuvG1Es16Fn
E0wy1PD5v7zzRPeZy7K5jP1WDKBugbQranZvefkVRz0mqGROvdhJ5GqTsZjbm3qm
mfZbGkkSUQJsJGl8sH07XKaw/q2XpSWNFKFLY4GRoecKClnpL7/3LxFyoWJuYcJk
7CUKHdJTWroKIcmcXUa3xlr/0hGyiXARA4JJK1lw22mXqF9c2yF/FA==x1VL
-----END PGP SIGNATURE-----

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Thanks everyone for their input. I''ll press on with Puppet and if I
run into performance issues then I''ll bring them up in this forum.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Wed, 2010-02-24 at 01:10 +0100, Thomas Bellman wrote:
> Trevor Vaughan top-posted:
> 
> > Just out of curiosity, do the ones that take longer happen to be 64
bit?
> 
> Well, yes, they are indeed 64 bit (x86_64).  But that doesn''t
> distinguish them from the quicker ones.  They are all running
> CentOS 5.4 for x86_64, and they all have identical quad-core
> Opteron CPUs and identical motherboards, RAID controllers, and
> disks.
> 
> There are differences though; some machines have dual processors
> (i.e. 8 cores) with 32 Gbyte RAM and run Xen, while some have
> single processors with 16 Gbyte RAM and do not run Xen.  I haven''t
> seen any *obvious* correlation between speed and non-Xen, dom0 or
> domU, or with amount of virtual CPU:s or RAM assigned to the
> domains, but as I said I haven''t really had time to analyze the
> problem properly.
It would be interesting in finding where (when?) the time is taken. I''m
wondering if it comes from the master or puppetd itself. Does running
with --debug gives more information.

I know Ohad found an issue around 0.24.5 about puppetd scanning $PATH to
find executables each time it needed to run yum/rpm (and possibly other
executables).
On his machines this was taking a lot of time (don''t ask why).
This has been fixed in 0.25, if I remember correctly, but maybe that''s
what you''re seeing.
-- 
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 Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Tuesday 23 Feb 2010 16:22:44 Lindsay Holmwood wrote:
> Performance, expressiveness, stability. Pick two.
> 
You make it sound like it''s impossible to write a well performing,
expressive
and stable system in C/C++, etc.  Surely you can''t think that?

I once had an idea of using puppet to also manage configuration on some 
embedded systems (routers, NAS, heck even tablets like maemo-based), that went 
quickly out the door once I realised how well performing ruby is.  Still I 
think it would be a valid use case.

Regards,

Michael


-- 
Michael Gliwinski
Henderson Group Information Services
9-11 Hightown Avenue, Newtownabby, BT36 4RT
Phone: 028 9034 3319

**********************************************************************************************
The information in this email is confidential and may be legally privileged.  It
is intended solely for the addressee and access to the email by anyone else is
unauthorised.
If you are not the intended recipient, any disclosure, copying, distribution or
any action taken or omitted to be taken in reliance on it, is prohibited and may
be unlawful.
When addressed to our clients, any opinions or advice contained in this e-mail
are subject to the terms and conditions expressed  in the governing client
engagement leter or contract.
If you have received this email in error please notify
support@henderson-group.com

John Henderson (Holdings) Ltd
Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern Ireland,
BT36 4RT.
Registered in Northern Ireland
Registration Number NI010588
Vat No.: 814 6399 12
*********************************************************************************

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Wed, Feb 24, 2010 at 1:59 AM, Michael Gliwinski
<Michael.Gliwinski@henderson-group.com> wrote:
> On Tuesday 23 Feb 2010 16:22:44 Lindsay Holmwood wrote:
>> Performance, expressiveness, stability. Pick two.
>>
>
> You make it sound like it''s impossible to write a well performing,
expressive
> and stable system in C/C++, etc.  Surely you can''t think that?
I don''t think that.

What I *do* think is that something like Puppet that needs to abstract
out a bunch of stuff across various platforms is only really going to
work as an open source project with a healthy and active community.

You''re much more likely to get such a community form around a high
level language than a lower level one.

I wouldn''t have contributed as much to Puppet as I''ve done if
it was
written in C/C++.

>
> I once had an idea of using puppet to also manage configuration on some
> embedded systems (routers, NAS, heck even tablets like maemo-based), that
went
> quickly out the door once I realised how well performing ruby is.  Still I
> think it would be a valid use case.
>
> Regards,
>
> Michael
>
>
> --
> Michael Gliwinski
> Henderson Group Information Services
> 9-11 Hightown Avenue, Newtownabby, BT36 4RT
> Phone: 028 9034 3319
>
>
**********************************************************************************************
> The information in this email is confidential and may be legally
privileged.  It is intended solely for the addressee and access to the email by
anyone else is unauthorised.
> If you are not the intended recipient, any disclosure, copying,
distribution or any action taken or omitted to be taken in reliance on it, is
prohibited and may be unlawful.
> When addressed to our clients, any opinions or advice contained in this
e-mail are subject to the terms and conditions expressed  in the governing
client engagement leter or contract.
> If you have received this email in error please notify
support@henderson-group.com
>
> John Henderson (Holdings) Ltd
> Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern
Ireland, BT36 4RT.
> Registered in Northern Ireland
> Registration Number NI010588
> Vat No.: 814 6399 12
>
*********************************************************************************
>
> --
> You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
>
>


-- 
nigel

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Brice Figureau wrote:
> It would be interesting in finding where (when?) the time is taken.
I''m
> wondering if it comes from the master or puppetd itself. Does running
> with --debug gives more information.
Maybe it does.  I do need to look into this sometime, but I won''t have
the time for yet a couple of weeks.
> I know Ohad found an issue around 0.24.5 about puppetd scanning $PATH to
> find executables each time it needed to run yum/rpm (and possibly other
> executables).
> On his machines this was taking a lot of time (don''t ask why).
> This has been fixed in 0.25, if I remember correctly, but maybe
that''s
> what you''re seeing.
I''m running 0.25.2.  Going from 0.24.8 to 0.25.x did make things go
faster.


	/Bellman

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Wednesday 24 Feb 2010 10:19:57 Nigel Kersten wrote:
> > You make it sound like it''s impossible to write a well
performing,
> > expressive and stable system in C/C++, etc.  Surely you can''t
think that?
> 
> I don''t think that.
> 
> What I do think is that something like Puppet that needs to abstract
> out a bunch of stuff across various platforms is only really going to
> work as an open source project with a healthy and active community.
> 
Agreed.
> You''re much more likely to get such a community form around a high
> level language than a lower level one.
> 
That is perhaps relative, but see below.
> I wouldn''t have contributed as much to Puppet as I''ve
done if it was
> written in C/C++.
> 
I see your point, but this is perhaps specific to the domain of configuration 
management systems?  I mean just look at some of the largest free software 
communities like KDE, which is primarily written in C++ which doesn''t
seem to
be in any way diminishing the number of contributors.


-- 
Michael Gliwinski
Henderson Group Information Services
9-11 Hightown Avenue, Newtownabby, BT36 4RT
Phone: 028 9034 3319

**********************************************************************************************
The information in this email is confidential and may be legally privileged.  It
is intended solely for the addressee and access to the email by anyone else is
unauthorised.
If you are not the intended recipient, any disclosure, copying, distribution or
any action taken or omitted to be taken in reliance on it, is prohibited and may
be unlawful.
When addressed to our clients, any opinions or advice contained in this e-mail
are subject to the terms and conditions expressed  in the governing client
engagement leter or contract.
If you have received this email in error please notify
support@henderson-group.com

John Henderson (Holdings) Ltd
Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern Ireland,
BT36 4RT.
Registered in Northern Ireland
Registration Number NI010588
Vat No.: 814 6399 12
*********************************************************************************

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

I see your point, but this is perhaps specific to the domain
of
> configuration
> management systems?  I mean just look at some of the largest free software
> communities like KDE, which is primarily written in C++ which
doesn''t seem
> to
> be in any way diminishing the number of contributors.
>
>
 Not the same "pool" of contributors? I mean, Puppet is for sysadmins.
Sysadmins like scripting languages. Better tools for the kind of work we do
normally than C/C++. That''s more or less the opposite situation from
KDE.

------------------------------

Jesús Couto F.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Wed, Feb 24, 2010 at 6:00 AM, Michael Gliwinski
<Michael.Gliwinski@henderson-group.com> wrote:
> I see your point, but this is perhaps specific to the domain of
configuration
> management systems?  I mean just look at some of the largest free software
> communities like KDE, which is primarily written in C++ which
doesn''t seem to
> be in any way diminishing the number of contributors.
I think so.  As a systems engineer, I reach for python and ruby very
frequently and can''t remember the last I reached for C/C++.  I believe
it was to write a cfengine module actually.

Puppet provides a natural way for me to integrate the scripting I
already do day to day into a sophisticated and robust system.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 24/02/10 3:00 AM, Michael Gliwinski wrote:
> I see your point, but this is perhaps specific to the domain of
configuration
> management systems?  I mean just look at some of the largest free software 
> communities like KDE, which is primarily written in C++ which
doesn''t seem to
> be in any way diminishing the number of contributors.
> 
> 
I suspect it''s the domain of sysadmins with problems to solve - who
make a significant portion of Puppet''s user base.  I have found most
sysadmins cut code in higher level languages - Perl, Python, Ruby
rather than C/C++.

To get good buy in from them then it''s going to be hard if you write
the tool in a lower level language.  I look at the pool of cfengine
and Nagios developers versus the pool of users as a (perhaps valid?)
example.

Regards

James Turnbull

- -- 
Author of:
* Pro Linux System Administration (http://tinyurl.com/linuxadmin)
* Pulling Strings with Puppet (http://tinyurl.com/pupbook)
* Pro Nagios 2.0 (http://tinyurl.com/pronagios)
* Hardening Linux (http://tinyurl.com/hardeninglinux)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEVAwUBS4VMISFa/lDkFHAyAQJgnQgAoNuiCE7BQmXpp/gm9ZjzkDsJEl+Lt4oD
S01AjyMBLenaUkqfj4aM4ZXf80MUyWO5Lj8OjEJqliqco2MJ3LJPYL6OD3wWAfZl
IutDby9edyZBSmioWS4+th0PBp20E34dud5YXUgau+oRAKxuZpF6evbv5134rgt2
GTv9XZrxneTrBojUioDK4wahdZ4lMMaY1M0cZq+bTzF7guH2wJbLdNuHKEq+Ghdm
M26rv/A0BQBlRXqLXH7cHvua213F2lEaZQFbe5Pw5JnCOmK3z4o9OuPq2cW9Mmni
/LXWfvr+8DtcDko4G20kK7+HJuD2xsgOy5rCYQc0nwAsuHaM75f87w==85ph
-----END PGP SIGNATURE-----

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Mon, Feb 22, 2010 at 03:37:15PM -0600, James Cammarata
wrote:
> 
> On Mon, 22 Feb 2010 21:17:52 +0000, Toby Riddell
<toby.riddell@gmail.com>
> wrote:
> > I received my copy of ;login (the Usenix magazine) today.
There''s an
> > article* comparing CPU utilisation of Puppet and Cfengine. To
> > abbreviate massively: Puppet requires much more CPU than Cfengine when
> > both verifying and fixing configuration.
> 
> I''m not really surprised by this, puppet is written in Ruby (an
interpreted
> language) vs CFengine which is written in C.
Has anyone tried puppet with Ruby 1.9?  It''s supposed to be a lot
faster than
1.8.  Haven''t tested it myself, though.

Cheers,

-- 
Eric Gerlach, Network Administrator
Federation of Students
University of Waterloo
p: (519) 888-4567 x36329
e: egerlach@feds.uwaterloo.ca

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Eric Gerlach wrote:
> On Mon, Feb 22, 2010 at 03:37:15PM -0600, James Cammarata wrote:
>> On Mon, 22 Feb 2010 21:17:52 +0000, Toby Riddell
<toby.riddell@gmail.com>
>> wrote:
>>> I received my copy of ;login (the Usenix magazine) today.
There''s an
>>> article* comparing CPU utilisation of Puppet and Cfengine. To
>>> abbreviate massively: Puppet requires much more CPU than Cfengine
when
>>> both verifying and fixing configuration.
>> I''m not really surprised by this, puppet is written in Ruby
(an interpreted
>> language) vs CFengine which is written in C.
> 
> Has anyone tried puppet with Ruby 1.9?  It''s supposed to be a lot
faster than
> 1.8.  Haven''t tested it myself, though.
It didn''t work when I tried it.  From what I remember, some of the
language syntax changes caused a few issues that
needed patching, and after I fixed those, the puppetmaster wouldn''t
work right in Passenger (spun off/locked up and
wouldn''t respond).  It looked like a hard road for little gain, so I
switched back to 1.8.

Craig Miskell



-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 24/02/10 17:31, Eric Gerlach wrote:
> On Mon, Feb 22, 2010 at 03:37:15PM -0600, James Cammarata wrote:
>>
>> On Mon, 22 Feb 2010 21:17:52 +0000, Toby Riddell
<toby.riddell@gmail.com>
>> wrote:
>>> I received my copy of ;login (the Usenix magazine) today.
There''s an
>>> article* comparing CPU utilisation of Puppet and Cfengine. To
>>> abbreviate massively: Puppet requires much more CPU than Cfengine
when
>>> both verifying and fixing configuration.
>>
>> I''m not really surprised by this, puppet is written in Ruby
(an interpreted
>> language) vs CFengine which is written in C.
> 
> Has anyone tried puppet with Ruby 1.9?  It''s supposed to be a lot
faster than
> 1.8.  Haven''t tested it myself, though.
It''s possible to run puppet on JRuby, which I expect might behave
better
than ruby 1.8 (especially because of the native threading of the JVM and
its superior GC).
-- 
Brice Figureau
My Blog: http://www.masterzen.fr/

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Tue, Feb 23, 2010 at 11:38:29AM +0200, Ohad Levy
wrote:
> On Tue, Feb 23, 2010 at 11:11 AM, Oliver Schad <puppet@oschad.de>
wrote:
> >
> >
> > Do you know process priorities? It''s very easy to run puppet
with this.
> > Most CPUs has so much idle times that puppet is not a problem. The RAM
> > usage could be a more significant problem in smaller systems.
> >
> Using nice is not an option with puppet, as all services/daemons that
puppet
> will start would be in the same nice level as puppet.
If only there was SMF for Linux.. ;-)

-- 
Marcin Owsiany <marcin@owsiany.pl>              http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
 
"Every program in development at MIT expands until it can read mail."
                                                              -- Unknown

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Wednesday 24 Feb 2010 15:56:17 James Turnbull wrote:
> On 24/02/10 3:00 AM, Michael Gliwinski wrote:
> > I see your point, but this is perhaps specific to the domain of
> > configuration management systems?  I mean just look at some of the
> > largest free software communities like KDE, which is primarily written
in
> > C++ which doesn''t seem to be in any way diminishing the
number of
> > contributors.
> 
> I suspect it''s the domain of sysadmins with problems to solve -
who
> make a significant portion of Puppet''s user base.  I have found
most
> sysadmins cut code in higher level languages - Perl, Python, Ruby
> rather than C/C++.
> 
> To get good buy in from them then it''s going to be hard if you
write
> the tool in a lower level language.  I look at the pool of cfengine
> and Nagios developers versus the pool of users as a (perhaps valid?)
> example.
> 
> Regards
> 
> James Turnbull
> 
Yes, that''s understandable.  I never said it would be good idea for
end-users
to write extensions in low level language.

But again, let me just mention two examples.

1. KDE: itself written in low-level language, provides a very good API and a 
set of bindings for quite a few higher level dynamic languages (Python, Ruby, 
JavaScript, and many others); makes the core well performing and easy to 
extend

2. Bazaar: itself written in high-level language (Python), optimizes the most 
demanding computations with extensions written in C (with Python-equivalent 
implementation as a fall-back in case extension wasn''t compiled); now
that
makes use of Python''s ability to easily interface with C/C++ modules,
don''t
know how that looks in Ruby''s case; anyway, plugins, extensions, even
systems
that build upon bzrlib are written in high-level language

Guess I''m just trying to say that there are options.  Mind you, IMO it
still
makes more sense to make the system more feature-complete first (1.0 release?) 
and then start thinking about such optimizations.

Regards,
Michael


-- 
Michael Gliwinski
Henderson Group Information Services
9-11 Hightown Avenue, Newtownabby, BT36 4RT
Phone: 028 9034 3319

**********************************************************************************************
The information in this email is confidential and may be legally privileged.  It
is intended solely for the addressee and access to the email by anyone else is
unauthorised.
If you are not the intended recipient, any disclosure, copying, distribution or
any action taken or omitted to be taken in reliance on it, is prohibited and may
be unlawful.
When addressed to our clients, any opinions or advice contained in this e-mail
are subject to the terms and conditions expressed  in the governing client
engagement leter or contract.
If you have received this email in error please notify
support@henderson-group.com

John Henderson (Holdings) Ltd
Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern Ireland,
BT36 4RT.
Registered in Northern Ireland
Registration Number NI010588
Vat No.: 814 6399 12
*********************************************************************************

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

> The version of CFEngine he is running is 3.0.1b3
> (released ??? Jan or Feb ''09, sometime, maybe?)
> 
> The version of Puppet he is running is 0.24.7
> (released 16-Dec-2008)
> 
> So, even though this article was just released, I think it was
> written a year
> ago. The author said these were the latest stable versions at the
> time of writing.
The author also mentions that: "In Puppet a server component is
mandatory [...]" (probably he missed out the "puppet"
interpreter) but
that "Cfengine’s configuration agent is independent of a server
component".

I suppose the benchmarks were made on a machine running puppetmaster +
puppetd, but cfengine was run in stand-alone mode. Probably puppet would
have performed a bit better if the manifests would have been run in
stand-alone mode too.

Marc


-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.