Magazine article comparing CPU usage of Puppet vs. Cfengine
Toby Riddell
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).
James Cammarata
On Mon, 22 Feb 2010 21:17:52 +0000, Toby Riddell <toby.r...@gmail.com>
wrote:
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.
Julian Simpson
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...).
Lindsay Holmwood
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
Patrick (kc7zzv)
> 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
tobyriddell
> 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
tobyriddell
> 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.
Oliver Schad
> > 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
Ohad Levy
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.
Aurelien Degremont
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 :
--
Aurelien Degremont
CEA
Lindsay Holmwood
>> 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...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Tim Stoop
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
James Cammarata
On Tue, 23 Feb 2010 08:57:37 -0800 (PST), Tim Stoop <tim....@gmail.com>
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.
tobyriddell
> 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
tobyriddell
> 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.
Thomas Bellman
> 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
Trevor Vaughan
Also, does using --tags do what you want in terms of testing speed?
Trevor
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users...@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
tvau...@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
Jeff McCune
> 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
Disconnect
Thomas Bellman
> 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?
Jeff McCune
> ..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.
Andrew Heagle
> 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.
>
> 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).
>
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
James Turnbull
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-----
tobyriddell
run into performance issues then I'll bring them up in this forum.
Brice Figureau
> 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!
Michael Gliwinski
> 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 sup...@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
*********************************************************************************
Nigel Kersten
<Michael....@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 sup...@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...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
>
>
--
nigel
Thomas Bellman
> 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
Michael Gliwinski
> > 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.
>
> 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.
Jesús Couto
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.
Jeff McCune
<Michael....@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.
James Turnbull
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-----
Eric Gerlach
>
> On Mon, 22 Feb 2010 21:17:52 +0000, Toby Riddell <toby.r...@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.
>
> 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: eger...@feds.uwaterloo.ca
Craig Miskell
> 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.r...@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
Brice Figureau
> 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.r...@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/
Marcin Owsiany
> On Tue, Feb 23, 2010 at 11:11 AM, Oliver Schad <pup...@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 <mar...@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
Michael Gliwinski
> 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
Marc Fournier
> 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