Establishing network connections in WSL is slow

[aseering]

Please use the following bug reporting template to help produce actionable and reproducible issues. Please try to ensure that the reproduction is minimal so that the team can go through more bugs!

• A brief description
  See subject. I haven't benchmarked the specific syscalls, but I have noticed empirically that a number of applications that I have that churn through sockets quickly are substantially (~10x) slower under WSL than under Linux.

• Expected results

Open up two terminal windows.

Linux$ python -m SimpleHTTPServer
(Just let this terminal sit there)

Then,

Linux$ time (for i in {1..10}; do curl http://localhost:8000 >/dev/null 2>&1; done)

real    0m0.303s
user    0m0.160s
sys     0m0.096s

• Actual results (with terminal output if applicable)

WSL$ python -m SimpleHTTPServer
(Just let this terminal sit there)

Then,

WSL$ time (for i in {1..10}; do curl http://localhost:8000 >/dev/null 2>&1; done)

real    0m2.584s
user    0m0.109s
sys     0m1.594s

Note that I didn't compare on identical hardware; the comparison is unfair in the wrong direction: The machine running WSL is much faster (modern Core i5 CPU) than the machine running Linux (older Intel Atom CPU -- I expect this operation to be CPU-bound) in this instance. So I would expect WSL to complete this operation significantly faster than Linux, when in fact it is a bunch slower.

Just for comparison / to get a sense of "is it the sender or the receiver that's slow in WSL?": (This is not the same physical machine so it's not a great test, but it's the same subnet on a gigabit LAN so latency should be relatively low. %sys and %user should be somewhat meaningful, at least.)

WSL$ time (for i in {1..10}; do curl http://Linux:8000 >/dev/null 2>&1; done)

real    0m2.245s
user    0m0.031s
sys     0m2.047s

Linux$ time (for i in {1..10}; do curl http://WSL:8000 >/dev/null 2>&1; done)

real    0m1.361s
user    0m0.140s
sys     0m0.092s

I have observed comparable slow-downs with more-optimized code that repeatedly opens sockets within a single application. I can cook up a tighter reproducer if you need one that doesn't rely on a low-performance Python server and a client that's launching a new process for every request.

• Your Windows build number
  15002

• Steps / All commands required to reproduce the error from a brand new installation
  See above. Let me know if you'd like more details.

• Strace of the failing command
  The strace is quite large and I'm not sure it's the most useful thing in this situation. Let me know if you'd like it; I can easily generate and post it.

• Required packages and commands to install
  I think curl, python, and time are all builtins? If not, they're in apt.

See our contributing instructions for assistance.

[aseering]

This is very much not a blocker for me. It just caught my attention so I figured I would post it.

It does in particular tend to make integration tests for Web applications run significantly slower under WSL than with the same code under Linux, since (in my experience at least) that type of test basically consists of a huge number of HTTP requests verifying correct behavior for each endpoint for a variety of different inputs.

[sunilmut]

Thanks @aseering. There is really not much that happens in WSL during the connect call. We very quickly hand it off to the Windows TCP/IP connect code. Though, we currently don't support non-blocking connect and I don't know if that is playing a role here. I have opened a task internally to track this. It looks difficult for this release, but we will take a look soon after. Thanks, as always for the wonderful reports.

[aseering]

Hm -- this may have been a red herring. My Insider machine had been acting up recently; I eventually realized that its CPU was sometimes (inconsistently) getting pegged at its lowest-power state regardless of CPU temperature or system load. (I have no idea why. I filed a report through the Feedback app.)

I just re-ran the WSL test while verifying that the CPU was running at full speed. Updated numbers:

$ time (for i in {1..10}; do curl http://localhost:8000 >/dev/null 2>&1; done)

real    0m0.663s
user    0m0.047s
sys     0m0.578s

Still significantly slower. But small-constant-factor slower; not log-scale-plot slower :-) Much more reasonable.

Feel free to close this out and/or de-prioritize it.

[aseering]

Also, I should note -- I don't know that the time is going to connect() specifically. curl is opening the socket, reading data from it, and closing it. It could be any combination of or interaction between the relevant syscalls.

[sunilmut]

Thanks @aseering for the update. I have readjusted the label such that this is more of a discussion now.

[sunilmut]

Just an update that non-blocking connect is on it's way and will also be available on Fall Creators Update.