众所周知，Ansible是基于ssh(当然还有telnet，winrm等连接插件)的自动化配置管理工具，其简单易用，无agent式的工作方式在很多场景中都有不少优势，不过也是由于这种工作方式导致了它没有其他c/s类的工具执行效率高，饱受其他C/S类工具使用者的讥讽，对此，Ansible官方也对Ansible的速度效率做了不少优化手段。
简要简介
| 参数名/优化类别 | 说明 |
| fact cache: | 将facts信息第一次收集后缓存到memory或者redis或者文件中。 |
| gather_subset | 可选择性的收集network,hardware等信息，而不是全部 |
| control_path | 开启ssh socket持久化，复用ssh连接 |
| pipelinling | 开启ssh pipelining,客户端从管道中读取执行渲染后的脚本，而不是在客户端创建临时文件 |
| fork | 提高并行执行主机的数量 |
| serial | 将play_hosts①中主机再分批执行 |
| strategy | 默认linear,每个主机的单个task执行完成会等待其他都完成后再执行下个任务，设置free可不等待其他主机，继续往下执行(看起来会比较乱)，还有一个选项host_pinned，我也不知道干嘛的 |
闲逛中无意发现了一个Mitogen的Ansible plugin，当前已迭代到0.28版本，看介绍说能提升1.2x ~ 7x以上的执行效率，着实惊人！
它通过高效的远程过程调用来取代ansible默认的嵌入式与纯python shell调用，它不会优化模块本身的执行效率，只会尽可能快的②去执行模块获取返回(执行模块前也是有一系列连接，发送数据，传输渲染脚本等操作的)来提高整体的效率，特性如下（摘自原文，自行翻译吧，英语渣，怕误导人）：
Expect a 1.25x – 7x speedup and a CPU usage reduction of at le
- One connection is used per target, in addition to one sudo invocation per user account. This is much better than SSH multiplexing combined with pipelining, as significant state can be maintained in RAM between steps, and system logs aren’t spammed with repeat authentication events.
- A single network roundtrip is used to execute a step whose code already exists in RAM on the target. Eliminating multiplexed SSH channel creation saves 4 ms runtime per 1 ms of network latency for every playbook step.
- Processes are aggressively reused, avoiding the cost of invoking Python and recompiling imports, saving 300-800 ms for every playbook step.
- Code is ephemerally cached in RAM, reducing bandwidth usage by an order of magnitudecompared to SSH pipelining, with around 5x fewer frames traversing the network in a typical run.
- Fewer writes to the target filesystem occur. In typical configurations, Ansible repeatedly rewrites and extracts ZIP files to multiple temporary directories on the t
版权声明：本文遵循 CC 4.0 BY-SA 版权协议，若要转载请务必附上原文出处链接及本声明，谢谢合作！ arget. Security issues relating to temporary files in cross-account scenarios are entirely avoided.
The effect is most potent on playbooks that execute many short-lived actions, where Ansible’s overhead dominates the cost of the operation, for example when executing large with_items loops to run simple commands or write files.
大体就是执行过程中主机使用一个连接(默认每执行一个task或者loop循环都会重新打开一次连接的)；渲染的执行代码暂存于内存中；减少多路复用ssh隧道的时间消耗；减少临时文件传输的带宽；代码重用，避免代码的重新编译成本等
实现原理的话，可以去看下官网解释，反正我是没怎么看懂
① .&nplay_hosts为内置参数，指当前正在执行的playbook中的主机列表
②. 尽可能快的 指到运行模块前的阶段
说了这么多，那么怎么配置呢？
安装配置
wget https://files.pythonhosted.org/packages/source/m/mitogen/mitogen-0.2.8.tar.gz
tar axf mitogen-0.2.8.tar.gz -C /opt/配置插件(修改ansible.cfg)
[defaults]
strategy_plugins = /opt/mitogen-0.2.8/ansible_mitogen/plugins/strategy
strategy = mitogen_linear注: mitogen中也有三种模式
- mitogen_linear: 对应原生的linear
- mitogen_free: 对应原生的free
- mitogen_host_pinned: 对应原生的host_pinned
插件配置很简单，我们来测试看看效果
我环境没有很多主机，这里测试只用5个主机，所以我用了loop循环来代替大量的任务，主要有如下task:
- gather facts
- 创建临时文件夹
- loop循环copy小文件指目标服务器(大文件带宽不够，大概1065个文件)
- loop循环执行shell一个echo(大概1000次)
- 删除临时目录
编写playbook
---
- hosts: cluster
tasks:
- name: Create directory
file: path=/tmp/soft state=directory
- name: Loop copy files
copy: src={{ item }} dest=/tmp/soft/
loop: "{{ lookup('fileglob','/opt/soft/*').split(',') }}"
- name: Loop execution shell
shell: echo {{ item }}
loop: "{{ range(0,1000) | list }}"
- name: Delete tmp
file: path=/tmp/soft state=absent测试对比
1.使用默认strategy策略(linear)
2.使用strategy策略为mitogen_linear
注：本例中我们开启了profile_tasks插件来统计task的任务时长(ansible.cfg中配置callback_whitelist = profile_tasks)
可怕。。。非常可怕，我们可以直观的看到原来的任务用了半个多小时(等的难受)，优化后只用了三分钟！！其中循环传输文件的任务提高了13倍，循环执行shell的任务提高了4倍，非常不错~
(该测试非理想场景，实际提升应根据特性考虑执行场景)
另外注意：
- 该插件目前支持Ansible2.3~2.8
- 该插件需要python(包括raw/script模块)
- 该插件会影响一些插件的执行过程，需要额外配置（become sudo模式，delegate_to等）
…. …
具体使用跟注意事项请参考官方文档.
参考文献
https://github.com/dw/mitogen/blob/master/docs/ansible_detailed.rst