Ошибка при параллельном запуске UI авто тестов тестов c помощью Nunit

Viktor_Yakushenko · 10.Апрель.2019 12:40:08

Привет! При параллельном запуске появляется ошибка (см. ниже) , кто сталкивался, как решали?

Есть тесты написанные на C#, Nunit, Webdriver (NgDriver)
Делаю параллельный запуск тестов в 2 или 4, потока из под Студии с помощью [Parallelizable(ParallelScope.Fixtures)]
Драйвер не статический, в TestBase для каждого класса создается собственный экземпляр драйвера и сюит тестов гоняется в одной сессии
После прохождения 10-15 тестов появляется ошибка
Обычно происходит на тестах где много полей ввода и большое количество проверок в форме
На виртуалке из под Тимсити тоже самое
Если не запускать параллельно, то все ок

Ошибка при обычном запуске локально из под студии и в Тимсити: Message: OpenQA.Selenium.WebDriverException : A exception with a null response was thrown sending an HTTP request to the remote WebDriver server for URL. The status of the exception was UnknownError, and the message was: Only one usage of each socket address (protocol/network address/port) is normally permitted Only one usage of each socket address (protocol/network address/port) is normally permitted

Ошибка при запуске в Selenium Grid локально из под студии
Message: OneTimeSetUp: OpenQA.Selenium.WebDriverException : The HTTP request to the remote WebDriver server for URL timed out after 60 seconds.
----> System.Net.WebException : The operation has timed out.

BabyRoot · 10.Апрель.2019 12:57:50

Попробуйте убивать браузер через какое-то количество тестов (если вы его не пересоздаёте перед каждым тестом, что конечно же увеличивает общее время работы).
Но вообще-то это похоже что у вас идёт утечка памяти в тестируемом приложении и надо бы как-то попытаться руками поймать эту ситуацию. Хотябы пройти руками пред-пред-последний, пред-последний и проблемный тест и посмотреть на ресурсы.

Viktor_Yakushenko · 10.Апрель.2019 13:20:03

Запуск драйвера для каждого теста помогает, но это дополнительно замедлит тесты, которые и так замедляются от параллельности. Надо будет еще попробовать заменить логику поиска при помощи FindElements на Xpath, решил попользоваться думал удобнее будет, но по перфомансу сильное проседание оказывается

Maczyuk_Aleksandr · 03.Октябрь.2019 11:13:50

У меня проблема аналогичная, хотя для каждого теста стартует отдельный браузер и драйвер, и икспасы используются

Viktor_Yakushenko · 03.Октябрь.2019 11:25:03

А вы используете NgDrver(NgDriver под капотом часто выполняет ExecuteScript метод) или часто выполняете ExecuteScript метод? У вас тесты содержат много действий?

Viktor_Yakushenko · 03.Октябрь.2019 11:48:30

Я решил проблему несколькими манипуляциями

Убрал NgDriver(Protractor) - под капотом часто выполняет ExecuteScript метод
Уменьшил частоту выполнения ExecuteScript во время ожидания страниц, объединил скрипты ожидания в один и выполняю одним разом + выполняю его только после навигации или каких то действий типа клик или ввод
Стал перезапускать драйвер чаще для массивных тестов

Но все равно мне кажется это полностью решит проблему, а позволит ее убрать для тех условий в которых я запускаю тесты

На Java это кстати походу пофиксили. И в Selenium 4 на C# Тут описана эта проблема

github.com/SeleniumHQ/selenium

WebDriver holds many TCP ports

opened 06:23PM - 07 Jan 16 UTC

closed 08:54PM - 08 May 18 UTC

Marrowbones

C-java I-performance

Hello, Apologies if this isn't the right way to ask this, but I can't find much… more information elsewhere. We have written a Java WebDriver application that we run many concurrent instances of, each of which runs many multi-step Selenium tests. As the number of concurrent tests has inreased, we've occassionally been hitting "java.net.SocketException: No buffer space" exceptions. We've applied relevant OS level patches for similar problems, so it's not (just) that. On further investigation, it seems that each WebDriver test holds dozens of ports open... and even after the driver has shut down cleanly, these are held in TIME_WAIT for some time. Is this expected behaviour? It's causing us quite a few resource problems, with thousands of sockets stuck in TIME_WAIT. For info, there seems to be many java > browser/driver and browser/driver connections, as well as (the more expected) browser > webpage sockets. Chrome seems to have less of the driver > Java connections than Firefox, but still has lots of the others. But generally it seems that every WebDriver interaction results in at least 3 sockets being hogged (Java > browser, browser > Java, browser <> webpage), sometimes more (example below) Is this all expected? Might it be amended in future? Cheers, Marc # ... TCP 127.0.0.1:7055 COMPUTERNAME:64378 TIME_WAIT TCP 127.0.0.1:7055 COMPUTERNAME:64380 TIME_WAIT TCP 127.0.0.1:7055 COMPUTERNAME:64385 TIME_WAIT TCP 127.0.0.1:7055 COMPUTERNAME:64409 ESTABLISHED [firefox.exe] ... TCP 127.0.0.1:64384 COMPUTERNAME:7055 TIME_WAIT TCP 127.0.0.1:64386 COMPUTERNAME:7055 TIME_WAIT TCP 127.0.0.1:64387 COMPUTERNAME:7055 TIME_WAIT TCP 127.0.0.1:64409 COMPUTERNAME:7055 ESTABLISHED [java.exe] ... TCP 10.111.34.81:56076 webserver-02:8080 TIME_WAIT TCP 10.111.34.81:56079 webserver-02:8080 ESTABLISHED [firefox.exe] TCP 10.111.34.81:56080 webserver-02:8080 ESTABLISHED [firefox.exe] TCP 10.111.34.81:56081 webserver-02:8080 ESTABLISHED [firefox.exe] #

github.com/SeleniumHQ/selenium

"Port" leaking in C# WebDriver.dll

opened 06:57AM - 12 Jun 17 UTC

closed 01:31PM - 13 Jun 19 UTC

kenhan168

C-dotnet

## Meta - OS: Windows 10, Windows Server 2008 R2 Selenium Version: WebDr…iver 3.4.0 Browser: Firefox and Chrome Browser Version: Firefox: 53.0.3 (32 bits) Chrome: Version 59.0.3071.86 (Official Build) (64-bit) ## Expected Behavior - WebDriver suppose to close the ports after each commands sent to ChromeDriver or GeckoDriver ## Actual Behavior - WebDriver keeps the ports open until the WebDriver quit(). This caused the ports run out from the OS when I had 8 parallel tests running together without open and close ChromeDriver or FirefoxDriver. ## Steps to reproduce -  Run the Selenium Tests with ChromeDriver or FirefoxDriver with any simple action, e.g. Navigate to a website. Repeat this step for 1000 time. Open a Windows Command Prompt, type: netstat -a -b You will find the ChromeDriver/GeckoDriver holds up about 1000 ports without releasing. I have amended the code in OpenQA.Selenium.Remote.DriverServiceCommandExecutor.cs, line 37 old code: this(driverService, commandTimeout, true) new code: this(driverService, commandTimeout, false) and OpenQA.Selenium.Remote.HttpCommandExecutor.cs, line 46: old code: : this(addressOfRemoteServer, timeout, true) new code: : this(addressOfRemoteServer, timeout, false) Retest again with the above step, we can see the ChromeDriver / Gecko Driver doesn't hold up the port any more. It seems for HttpWebRequest object, even it is out of scope, if its' KeepAlive property is true, the .net runtime holds it until the WebDriver is quit and closed. In theory, I can't think of HttpCommandExecutor should have HttpWebRequest should have KeepAlive = true as it looks like HttpCommandExecutor is running stateless commands. Maybe you can consider to remove the passing in of the attribute to avoid future problem. Kind regards Ken Han Self Service Tech Lead Fairfax Media Australia

github.com/SeleniumHQ/selenium

Should use HTTP keep alive to avoid port exhaustion

opened 01:18AM - 11 Apr 18 UTC

closed 05:22PM - 15 Dec 18 UTC

awarecan

C-dotnet C-nodejs

## Meta - OS: Windows 7, 10 Selenium Version: 3.8.1 Browser: Chrome Brows…er Version: 65.0.3325.181 (64-bit) Node.js: 8.11.1 ## Expected Behavior - During the test, TCP connection should be reused ## Actual Behavior - Each WebDriver command will create a new TCP connection to ChromeDriver ## Steps to reproduce - ```JavaScript await browser.get('https://www.google.com/'); for (let i=0; i<50000; i++) { await browser.getCurrentUrl(); } ``` use `netstat -na` to monitor the number of TCP connection in TIME_WAIT state while you are running above code. You will see massive amount of TCP connections. If you are using a powerful box and has default Windows TCP/IP configuration, you will hit ephemeral port exhaustion very soon. ## Note - This was [a well known issue related with ChromeDriver](https://bugs.chromium.org/p/chromedriver/issues/detail?id=2183). However ChromeDriver has [a dirty fix](https://chromium.googlesource.com/chromium/src/+/736efbc1c284f9b85d7dcda22771e23786def5d5%5E%21/#F0) in 2.35 release. It requires client set `Connection: keep-alive` HTTP header, see the discussion in #4162 and #3457 Now, we finally have chance to resolve this issue in selenium-webdriver side by passing in an Agent with keepAlive option while creating HttpClient in createExecutor() function.