Performance optimizations

Operating a Puppet master gives you numerous benefits over just using puppet apply on all your machines. This comes at a cost, of course. The master and agents form a server/client relation, and, as with most such constructs, the server can become the bottleneck.

The good news is that the Puppet agent is a fat client. The major share of the work inspecting file contents, interfacing with the package-management subsystem, services subsystem, and much more is done by the agent. The master only has to compile manifests and build catalogs from them. This becomes increasingly complex as you hand over more control to Puppet.

There is one more task your master is responsible for. Many of your manifests will contain file resources that rely on prepared content:

file { '/usr/local/etc/my_app.ini':
  ensure => file,
  owner  => 'root',
  group  => 'root',
  source =>  
  'puppet:///modules/my_app/usr/local/etc/my_app.ini',
}

The source parameter with a URL value indicates that the file has been pregenerated and placed in a module on the Puppet master (more on modules in Chapter 5, Combining Classes, Configuration Files, and Extensions into Modules). The agent will compare the local file with the master's copy (by checksum) and download the canonical version, if required. The comparison is a frequent occurrence in most agent runs; you will make Puppet manage a lot of files. The master does not need a lot of resources to make this happen, but it will hinder fluent agent operation if the master gets congested.

This can happen for any combination of the following reasons:

• The total number of agents is too large
• The agents check in too frequently
• The manifests are too complex
• The Puppet server is not tuned adequately
• The master's hardware resources are insufficient

There are ways to scale your master operation via load balancing, but these are not covered in this book.