On Thu, Feb 18, 2010 at 8:04 AM, Brice Figureau <[email protected]> wrote: > On Thu, 2010-02-18 at 07:52 -0800, Nigel Kersten wrote: >> +puppet-users, puppet-dev to catch the developer-y folks too. >> >> >> How, if at all, do any of you do capacity planning with Puppet? >> >> I've worked out a snippet of ruby code that will take the cached fact >> data from the servers, and use that to issue a bunch of catalog >> retrieval requests. I ended up modifying my auth.conf (such an >> awesomely flexible setup) > > Thanks :-)
It really is great work Brice. It's as simple as changing the first auth definiton to: # allow nodes to retrieve their own catalog (ie their configuration) path ~ ^/catalog/([^/]+)$ method find allow $1 allow my-benchmarking-client > >> to allow a given certificate to request >> anyone's catalogs, which made this all a lot easier. >> >> I'm now looking at jmeter to issue the https with client certificate >> GET requests, and before I dive too deeply into scripting jmeter, I >> thought I'd see what anyone else is doing in this space. > > I'm not familiar with jmeter, but I suppose you want to measure request > service time. But what would also be interesting is memory and or CPU > consumption on the host. I'm not sure jmeter can gather those metrics by > itself. I agree that's useful info to get, but there's a sense in which I don't care what state the puppetmaster is in, so long as it can still provide catalogs to clients. I'm ultimately interested in working out exactly how many simultaneous clients I can support with a given configuration. A further step would be to mix two kinds of benchmarks. One that just sees how many simultaneous clients can be served before catalog provision fails, and another that does a file retrieval for every file resource in the catalog after that. I should mention the idea of jmeter came from James Bellenger's blog at http://www.forwardcamegrendel.org/benchmarking-puppet-jmeter > >> It would be awesome if we could put something into the source >> distribution to do this in a standard manner so we can all compare >> performance on different platforms and ruby stacks. > > That's a really interesting idea. I'd really like to compare MRI to > JRuby for Puppet deployement (or even to compare a glassfish to > something else). > >> This is all a lot easier with the RESTful API than it was with XMLRPC >> by the way. >> >> There was the puppet-test script in ext/, but as per >> http://projects.reductivelabs.com/issues/3183 it doesn't appear to >> have been updated for 0.25.x clients. > > That's too bad, it was really useful to trigger catalog compile to > profile the master. > >> Anyone else interested in collaborating on something to provide >> uniform server benchmarking with pretty graphs for management? > > It's not like I'd have the time to help, but at least I can offer to > discuss implementation or concepts... > -- > Brice Figureau > Follow the latest Puppet Community evolutions on www.planetpuppet.org! > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/puppet-dev?hl=en. > > -- nigel -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
