Какие шаги я могу предпринять для проверки подключения контроллера?
Как я могу убедиться, что мой сервер сборки tfs может обмениваться данными с контроллером для выполнения нагрузочного теста?
Моя компания пытается автоматизировать нагрузочное тестирование, и для этого мы используем сборку tfs. У меня есть задача командной строки, чтобы фактически запустить нагрузочные тесты. Для наглядности это выглядит так:
Command Line Task
Tool: MSTest.exe
Arguments: /testcontainer:"some load test.loadtest" /testsettings:"some test settings.testsettings"
Когда я запускаю сборку, она истекает через 3-4,5 минуты и выдает мне эту ошибку:
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
Я попробовал несколько вещей, чтобы проверить подключение контроллера, но я не уверен, что достиг ответа, который я ищу.
Первым делом я попытался перезагрузить контроллер, но это ничего не изменило.
Затем я вошел в vs2017 и открыл редактор нагрузочного теста. Оттуда я вошел в Manage test controllers
. Диалоговое окно контроллера установлено на правильный контроллер, и агенты, которыми он управляет, находятся на Ready
.
Затем я посмотрел на настройки теста и убедился, что <RemoteController/>
также был установлен правильно. Я сделал это больше, чтобы подтвердить, что ошибка не в самих файлах. Таким образом, тайм-аут должен происходить из-за проблем с соединением между сервером или контроллером.
Я знаю, что контроллер использует определенный порт для входящего трафика, порт 6901, поэтому я проверил соединение порта с помощью .NET TcpClient в 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
При условии, что контроллер включен, $client
всегда возвращает, что он может подключиться к $server
. Есть ли какие-либо свойства помимо Connected
объекта TcpClient
, которые могли бы дать мне больше информации о его соединении? Поскольку сервер сборки все еще не работает, несмотря на то, что $client
, по-видимому, может подключаться. Нужно ли давать серверу сборки конкретный порт для подключения? Разве это не должно делать это автоматически?
Я попытался tracert
с помощью другой задачи командной строки, чтобы посмотреть, смогу ли я определить, где истекает время ожидания сервера:
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.
Может ли 4-й прыжок быть там, где зависает сервер сборки? Кажется, что несмотря на тайм-аут на переходе 4, агент все еще мог пропинговать контроллер. Если мне нужен 4-й прыжок, как мне его исправить? Это не дает мне никакой информации о том, куда хотел пойти 4-й прыжок.
Итак, в общем, я пытаюсь запустить нагрузочный тест через задачу командной строки в tfs, используя MSTest.exe. Когда я запускаю сборку, я получаю сообщение об ошибке тайм-аута, которое, по моему мнению, означает, что сервер сборки не может связаться с контроллером.
Я попробовал несколько идей для устранения неполадок, но мне не удалось решить проблему или пролить свет на то, как действовать дальше.
Как я могу определить, где произошла ошибка связи?
Какие другие способы устранения неполадок существуют для решения этой проблемы?
Для будущих тестов нагрузки, как я могу проверить, чтобы убедиться, что сервер сборки может обмениваться данными с контроллером?