Alright took me a bit of time to get back to this. I think I’m on all the correct versions but I’m still seeing around 23 seconds to create a directory.
mperzel@mdl-depl03:/opt/ansible/ansible-test/win_file> ansible --version
ansible 2.0.0 (winrm_put_file a471bcaef4) last updated 2015/11/03 08:17:28 (GMT -500)
lib/ansible/modules/core: (detached HEAD 211196bdf6) last updated 2015/11/03 08:17:59 (GMT -500)
lib/ansible/modules/extras: (detached HEAD 5d4474a2b2) last updated 2015/11/03 08:18:01 (GMT -500)
config file = /etc/ansible/ansible.cfg
configured module search path = None
mperzel@mdl-depl03:/opt/ansible/ansible-test/win_file> pip show pywinrm | grep Version
Metadata-Version: 1.0
Version: 0.1.1
I’m not really sure how to interpret the output put I put together a gist with ANSIBLE_DEBUG=1.
https://gist.github.com/perzizzle/ec143d8e4990fe56b1d3
Matt,
Did these improvements make it into ansible 2.0.1? I’m working on upgrading our infrastructure and running the winrm tests isn’t showing the improvement I was expecting. I haven’t been able to find any documentation about when these fixes were going to make into devel or a stable release.
Thanks,
Michael
All of this shipped in 2.0.0 and pywinrm 0.1.1. You seem to have something very … special? going on that I’ve never figured out. The times you’re seeing are universally abysmal - I’ve seen better times from customers running stuff over satellite connections.
You might want to try the new pywinrm 0.2.0 RC (see recent post here) - the entire guts got switched out, but I’m guessing you have something broken in Windows itself (major delay in AD auth or something) that’s introducing those delays… But try the new pywinrm out just for giggles- on a normal local setup, it’s still good for ~20% speed boost for most things.
Will do. Currently ansible is authenticating with a local Windows user so I wouldn’t expect AD to be an issue but the connection times are truly abysmal. Maybe I’ll see if the new AD authentication makes things better 
I’ve pulled in a few other people here to see if they have any ideas as well.
I assume you are still seeing performance similar to https://gist.github.com/perzizzle/ec143d8e4990fe56b1d3 ?
Looking back at the debug output you seem to have multi-second waits while modules execute and while transferring files.
I can only suggest digging into the network side of things, although that wouldn’t explain why the module runs as slow.
Hope you get a resolution - it definitely can work a lot faster than you are seeing.
Jon
I’m actually currently seeing even worse performance than that on a few nodes. I did a network capture and there are a bunch of just over 5 second delays between packets.I have no clue whats causing it. There aren’t any broken connections in the trace so I don’t think its a network issue. I think its something on the windows server itself. On the windows side, I’ve looked at the powershell/winrm versions, cpu and memory utilization and nothing is jumping out to me.
We are running windows server 2012 R2. What version are you guys using? I want to stand up an entirely vanilla windows server and test against it to see if I can isolate the cause. Can you also let me know how long the winrm tests take for in in ansible 2.0.1 so I have something to benchmark against?
Thanks,
Michael
I’m hitting windows server 2012 R2
Do you have tunnels between you and the windows boxes?
I wonder if this is similar to the situation you are in: https://ask.wireshark.org/questions/28060/delay-in-http-status-packet-and-first-tcp-segment
or perhaps this one:
https://ask.wireshark.org/questions/52019/strange-tcp-behavior-after-packet-loss-1-packet-at-a-time-despite-large-window-5-sec-delay
I’ve only skimmed but they sound similar to what you are seeing
These are my benchmarks for running all the integration tests:
Windows integration tests
1.9.4 27 mins 54 seconds
2.0.0.2 19 mins 4 seconds
I think actually 2.0.0.2 figure was against 2 hosts (1 2008R2 and 1 2012R2), the 1.9.4 tests I am fairly certain were against a single 2012R2.
ansible was running under Lubuntu 14,04 on the vm host and the windows vms were running inside virtual box on the same host.
Hope this helps,
Jon