Accelerators and Tradeoffs

Once pipelining and multiplexing are on, the remaining overhead is Ansible re-forking and re-connecting for chunks of work, and the best-known answer is Mitogen for Ansible — a third-party plugin that holds persistent Python interpreters on each target and routes calls to them, often cutting wall-clock time dramatically. The catch is exactly that it is third-party and out-of-tree.

Mitogen hooks deep into Ansible's connection and execution internals, so a new ansible-core release can break it, and that compatibility risk is the whole decision. For most fleets, enabling pipelining first answers the speed question without taking on an unsupported dependency — and treating Mitogen as if it were an official, supported feature is the mistake this topic is built to prevent.

Where the Remaining Overhead Lives

With pipelining and ControlPersist on, the SSH handshake and the extra per-task round-trips are already handled. What is left is Ansible repeatedly forking a Python process and re-establishing execution context for each task — the cost of standing up the machinery to run a module, paid over and over across a long, task-heavy play. That is the gap an accelerator targets. It is not the SSH layer pipelining already optimized, so reaching for an accelerator before pipelining is solving the wrong problem.

Mitogen for Ansible

Mitogen installs a strategy plugin you select as strategy: mitogen_linear. Instead of re-forking and re-connecting per task, it keeps long-lived Python interpreters running on the targets and proxies module calls to them, so the per-task fork and context setup mostly disappears. The reported speedups are large — multiples, not percentages, on the right workload — which is exactly why people reach for it. On a fleet where per-task fork cost dominates, that is a real and substantial win.

The Third-Party, Out-of-Tree Catch

Mitogen is not part of ansible-core and is not maintained by Red Hat. It is a separate project that patches into private Ansible internals, which is what makes the speedup possible and also what makes it fragile: an ansible-core upgrade can change those internals and break Mitogen, and you then wait on a separate project to catch up before your pipeline runs again. It is not an officially supported path, and treating it as one — pinning production to it as though Red Hat stands behind it — is the central mistake.

The Deprecated History — accelerate and fireball

Accelerators have a graveyard, which is worth knowing as context for how permanent any of them is. Older Ansible shipped fireball and later the accelerate mode — daemons that opened a faster channel to targets. Both were deprecated and removed: they added a daemon to manage and a security surface to defend, and pipelining covered most of the gain they offered for none of that cost. If a stale playbook or an old guide tells you to enable accelerate or fireball, it is pointing at a feature that no longer exists.

When the Complexity Is Worth It

Mitogen earns its risk on very large fleets, or on fact-heavy and task-heavy plays where the per-task fork cost genuinely dominates and minutes of wall time matter on every run. There the measured win can clear the maintenance cost of an out-of-tree dependency. For Larkspur's 6 prod web hosts, enabling pipelining is almost certainly enough — the per-task fork cost is small at that scale, and the unsupported dependency isn't worth taking on for a win that won't move the deploy clock meaningfully. Profile first; adopt only if the number justifies the risk.