Контроль состояния selenium-grid ноды и управление ей

webdriver
, ,
#1

Всем привет. Использую старый добрый грид. Хаб у меня расположен на вин-сервере, нода - на убунту-сервере (кроме ноды там ничего не запущено). Селениум сервер, хром, драйвер - последние, убунта 16.04.

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

В текущий момент реализовано костылём. Как показала практика, в момент падения количество свободной оперативной памяти на сервере снижается до ± 25 процентов, был написан скрипт которой периодично чекает память и перезагружает целиком сервер.

Интернет говорит о недостатке ресурсов, но, у меня очень специфичные тесты, длятся 1-2 секунды, но их довольно много. Т.е. каждую минуту запускается около 20 тестов. Параллельно редко бывает больше 2 сессий и по железу я сильных перегрузок не вижу во время работы.

Пытался прикрутить какой-нибудь юникс-процесс-менеджер, но проблема в том, что когда сессии мертвы, процесс ноды-то живой, а соответственно не совсем понятно на что ссылаться. Можно было бы как условие слать запрос на ноду с пробой получить сессию, но кажется тоже костыльным метод. Возможно у кого-то есть красивые решения.

Распространённые ошибки:

  1. Error forwarding the new session Empty pool of VM for setup Capabilities {browserName: chrome, goog:chromeOptions: {args: [headless, window-size=1200x600, no-sandbox]}}
  2. The HTTP request to the remote WebDriver server for URL http://localhost:11298/wd/hub/session timed out after 60 seconds.
  3. A exception with a null response was thrown sending an HTTP request to the remote WebDriver server for URL http://localhost:11298/wd/hub/session. The status of the exception was KeepAliveFailure, and the message was: The underlying connection was closed: A connection that was expected to be kept alive was closed by the server.
  4. Session [**] was terminated due to PROXY_REREGISTRATION

#2

Зачем вам старый грид? юзайте ноду и хаб из докера или в обще селенойд.

На всякий случай оставлю это тут.

version: "2"
services:
  selenium-hub:
    image: selenium/hub:3.8.1
    container_name: selenium-hub
    ports:
      - "4444:4444"
  chrome:
    image: selenium/node-chrome:3.8.1
    depends_on:
      - selenium-hub
    environment:
      - HUB_PORT_4444_TCP_ADDR=selenium-hub
      - HUB_PORT_4444_TCP_PORT=4444
  firefox:
    image: selenium/node-firefox:3.8.1
    depends_on:
      - selenium-hub
    environment:
      - HUB_PORT_4444_TCP_ADDR=selenium-hub
      - HUB_PORT_4444_TCP_PORT=4444
1 лайк
#3

+1 за Selenoid

Если Вы всё же хотите остаться на Selenium Grid, то хотя бы перейдите на ноды в docker контейнерах.

Нода у Вас одна?

#4

@ordeh да, я знаю, что такое селеноид. Но в целесообразности его использования надо ещё убедить заказчика. С учётом специфики моих тестов (тесты длительностью 1-2 секунды, но ранаются каждые 3-4 секунд) будет ли это полезным ? Только контейнер с хромом будет подниматься несколько секунд. Я так понимаю есть вариант ранать контейнер не для каждого теста, а для “пачек”, возможно в этом случае будет обоснованно.

@NikS ноду в докер-контейнере всё-равно прийдётся как-то контроллировать. Вопрос - как ?

#5

Ноду не надо контролить, убиваете контейнер и все, когда надо поднимаете.
Касательно пачки тестов в контейнере, то так и делают, никто не ранит 1-2 теста в отдельной среде.

1 лайк
#6

можно написать сервлет который запускается по своему route и с пом которого грид сообщает о своем каком нибудь health check metric (eсть же com.sun.jna.Library.

if you really like it подтвердите у меня даже гдето был проект готовый…

docker is ИМХО extra overthead в данном случае…

#7

Если не сложно - киньте проектик. По-крайней мере можно будет сравнить по сложности\оверхедности все варианты.

#8

@ctrlv one i referrredto originally was based on someone’s gist

but it won’t be of much use as long as hub and nodes are on different hosts

#9

Как уже было сказано, не надо её контролировать просто пересоздавайте контейнер.

Главными аргументами могут быть:

  • стабильность тестов за счёт минимизации падения тестов из-за нестабильности окружения
  • усилия и время для перехода на Селенойд минимальны - в коде будет работать та же ссылка для доступа к браузеру
  • комьюнити с нормальным тех саппортом (разработчики Селенойд доступны в Телеграм чате и быстро отвечают)
  • меньше ресурсопотребляемость (проверено на себе)
  • легкая масштабируемость

Обычно в ноде открытие браузера занимает секунды 3.

Контейнер в Селенойде поднимается при создании сессии браузера и закрывается при закрытии браузера. Т.е. Запуск нескольких тестов в одной браузерной сессии будет означать, что эти тесты будут выполнятся в одном контейнере.

1 лайк