0

What steps can I take to test the connectivity of a controller? How can I ensure that my tfs build server is able to communicate with a controller in order to perform a load test?

My company is trying to automate load testing, and to accomplish this we are using a tfs build. I have a command line task to actually start the load tests. To visualize, it looks like this:

Command Line Task
Tool: MSTest.exe
Arguments: /testcontainer:"some load test.loadtest" /testsettings:"some test settings.testsettings"

When I run the build, it times out after about 3-4.5 minutes and gives me this error:

Failed to queue test run 'some load test': A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond

I've tried a few things to test the connectivity of the controller, but I'm not sure I've reached the answer I'm looking for yet. The first thing I tried was to restart the controller, however that didn't change anything. I then went into vs2017 and opened up the load test editor. From there I went into Manage test controllers. The controller dialogue box is set to the correct controller, and the agents it's controlling are at the Ready. Then I looked at the test settings, and verified that the <RemoteController/> was also set correctly. I did this more just to confirm that the error isn't with the files themselves. So, the timeout should be happening due to some connection problem between the server or the controller.

I know that the controller uses a specific port for incoming traffic, port 6901, so I checked the port connection using a .NET TcpClient in PS:

$server = 'mycontroller'
$port = 6901
$client = New-Object Net.Sockets.TcpClient
try{
    $client.Connect($server, $port)
    $msg = "Connected to $server on Port $port"
} catch {
    $msg = "Could not connect to $server on Port $port"
} finally {
    $client.Dispose()
}
write-host $msg

Provided the controller is turned on, $client always returns that it is able to connect to $server. Are there any properties besides Connected a TcpClient object has that could give me more information about its connection? Because the build server still times out despite $client seemingly being able to connect. Do I need to give the build server the specific port to connect to? Shouldn't it do that automatically?

I tried tracert through another command line task to see if I could pinpoint where the server was getting timed out:

2019-07-10T20:28:32.9051572Z C:\Windows\system32\cmd.exe /c "TRACERT.exe atsvstctstvm400"
2019-07-10T20:28:32.9271264Z Tracing route to mycontroller.local [10.208.3.56]
2019-07-10T20:28:32.9281250Z over a maximum of 30 hops:
2019-07-10T20:28:37.7253994Z   1     1 ms    <1 ms    <1 ms  10.200.0.5 
2019-07-10T20:28:38.7269952Z   2    <1 ms    <1 ms    <1 ms  10.50.0.2 
2019-07-10T20:28:39.8534160Z   3    38 ms    39 ms    38 ms  172.20.0.2 
2019-07-10T20:28:52.3918376Z   4     *        *        *     Request timed out.
2019-07-10T20:28:52.5396304Z   5    48 ms    48 ms    48 ms  10.208.3.56 
2019-07-10T20:28:52.5396304Z Trace complete.

Could the 4th hop be where the build server is getting hung up on? It seems like despite the timeout on hop 4, the agent was still able to ping through to the controller. If it is the 4th hop I need to be concerned with, how do I even go about fixing it? It doesn't give me any information about where the 4th hop wanted to go.

So, in sum, I'm trying to run a load test through a command line task in tfs using MSTest.exe. When I run the build, I get a timeout error, which I believe means that the build server is unable to communicate with the controller. I've tried a few ideas for troubleshooting, but I haven't been able to resolve the issue or shed any light on how to proceed. How can I pinpoint where the communication error is? What other troubleshooting solutions are there to resolve this issue? For future load test runs, how can I test to ensure that the build server is able to communicate with the controller?

  • What TFS version? What Test Agent version? Can you add the correct tags? – jessehouwing Jul 11 '19 at 20:11
  • FYI: The MsTest agent infrastructure is deprecated in favor of the new Pipeline agent. – jessehouwing Jul 11 '19 at 20:11
  • And Visual Studio Load testing has also been deprecated and will no longer be part of future Visual Studio versions. https://devblogs.microsoft.com/devops/cloud-based-load-testing-service-eol/ – jessehouwing Jul 11 '19 at 20:13
  • @jessehouwing I've edited the tags to be more specific. I'm using tfs 2017 and the agent version is 1.105.7. – James Conner Jul 11 '19 at 20:48
  • 1.105.7 looks like the build agent. What test agent/controller version is mstest connecting to? Also 2017 or an older one? Is the agent updated to the latest update/servicepack? – jessehouwing Jul 11 '19 at 21:06

0 Answers0