You should be able to use the persistent connection capabilities we built
for networking here. It will allow the connection plugin to persistent
from task to task and only shutdown the session once the play has
completed. When you get ready to look at implementing this, we can go over
the
Looking at persisted connections/shells is definitely something we want to
look at and because 2.6 is going to be a stabilization release from the
core team 2.7 is where we will start looking into it. WinRM has 2
components that make it really slow compared to SSH;
* The network latency and
Awesome,
I guess it's also worth exploring where the slowness comes from. I'm pretty
sure the process spinup/spindown is a factor, but Ansible is also pushing
files across the wire (xml-based, so that's also probably slow). Not sure
if Matt has done any tracing to try and determine the "call
I'd looked at something like this awhile back.
Reusing the same shell_id across tasks/plays is one way to eliminate the
need for the open_shell and close_shell requests per task. There would
still be a new HTTP connection with authentication for each task, but not
the overhead of a new process.
Has there been any dicsussion around session mgmt in Ansible's WinRM
implementation? I don't know much about the protocol-level workings of
Ansible, but as far as I can see:
- Each task in a play is treated fairly independent (open session, do winrm
things, close session).
- This leads to
