Pull to refresh

Comments 31

А какой такой «тяжелой» нагрузкой занимается хаб, что он может обслуживать насколько мало нод?
Нагрузка на хабы у нас более менее обычная: открытие страниц, выполнение действий в текстовых полях, снятие скриншотов и т.п. Тем не менее десятки нод на одном хабе приводят к ощутимым тормозам, даже на мощном железе.
Ваш ответ ничего не объясняет. Я понимаю в чем состоит нагрузка на ноду — она занимается парсингом страниц, рендерингом в браузере и обработкой всяких яваскриптов. Но я не понимаю чем занят хаб. Интуитивно кажется, что он должен быть I/O-bound, но вы утверждаете, что он упирается в CPU. Что кажется неправильным и могло бы быть исправлено путем профилирования и устранения бессмысленных занятий, пожирающих проц на хабе.
Мне кажется Selenium не сильно оптимизирован, поэтому собственно такая история.
Тут на самом деле несколько аспектов
1. Хаб так или иначе держит таблицу доступных нод и постоянно обменивается с ними данными, пишет логи итп. (видимо действительно что-то из этого он делает неоптимально). Наш прокси, при этом, крайне легковесный, и его реализация изначально позволяет бесконечно масштабироваться за балансером.
2. При этом, как показали наши опыты, действительно есть предел производительности хаба, который, видимо, пропорционален железу. На небольших машинках в облаке 2хядерный хаб плохо держит более 20 нод. (ранее у нас была клиентская балансировка и хабы стояли на железе, тогда было просто 16 хабов и отдельные ноды)
3. Мы не изучали подробно внутреннюю архитектуру хаба, тк на данном этапе переписывать и оптимизировать хаб своими силами не входило в наши планы. Держать свою кастомную реализацию хаба мы не хотели тем более.
4. При этом одной из задач, которую мы решали, являлась задача повышения надежности. Один хаб, выходя из строя, тащит за собой весь грид. Два — половину.
5. Организовав конфигурацию с большим количеством машин, содержащих хаб и 5 изолированных нод, мы решили сразу три задачи — строго лимитировали нагрузку на один хаб, убрали фактор хаба как точки отказа и при этом остались в рамках стандартных непатченных selenium артефактов.
На сколько я помню сам selenium-server содержит код как хаба, так и ноды (собственно роль банально задается через флаг role). Что наталкивает на мысль о том, что в принципе имеем в итоге большой комбайн который вроде как умеет все. Причины видимо исторические.
То-то в я браузере вкладки падают и падают. Уже смотрю в сторону вивальди, а то задолбало наблюдать сие
В техподдержку писать не пробовали? Мне вот например отвечали и помогали.
мне тоже, только проблемы были не мои, а браузера. А тут на их новомодной почте (интерфейс) как начало падать пару дне назад, что пришлось вернуть классический интерфейс ну и заодно начать вивальди для себя готовить, за которым слежу с первого билда. Нет, и не собираюсь. Ибо в данном случае, это ни к чему не приведет. Проблема того что внезапно разные вкладки само собой падают в такие сообщения имеется давно, а воз и ныне там.
Хм… Вот у меня тоже новый интерфейс почты, и бета версия браузера — и пока ни разу не падало на ней. Вообще если они просто падают, но никто не сообщает в техподдержку — то чинить будут долго — анализ логов обычно имеет меньший приоритет, чем обращения в техподдержку. И далеко не всегда по логам можно понять сценарий воспроизведения. Но вот чем больше обращений в техподдержку — тем выше шанс, что проблеме повысят приоритет.
У вас много табов открыто?
В среднем — от десятка до двух, но в некоторые моменты бывало 3-4 десятка
может дело в этом. у меня не опускается ниже 2ух десятков.
Отписал лицам, отвечающим за разработку Яндекс.Браузера. В ближайшее время они отреагируют на ваш комментарий.
Напишите, пожалуйста, через «Сообщить о проблеме» в меню браузера (в этом случае передается еще техническая информация о компьютере). Желательно описать сценарии, когда падения происходили.
Я уверен — виноват именно роутер из статьи, поэтому лучшего места для этот репорта не найти
Я не понял вот эту фразу:
мы выяснили, что для виртуальной машины с двумя VCPU и 4 Гб памяти оптимальным является сочетание хаба и пяти нод

Я всегда думал, что каждая нода ставится на отдельную машину. А вы тут предлагаете на одну машину ставить 5 нод. В чём смысл?
Поскольку мы работаем с большими объемами браузеров, то довольно важный вопрос — об эффективности использования железа. Типичный железный сервер имеет 24 и более ядра и больше 50 Гб памяти. Для того, чтобы не думать об аппаратном уровне мы используем облако. Для экономии ресурсов и обеспечения изоляции браузеров на одной виртуальной машине мы поднимаем несколько нод в разных виртуальных рабочих столах по 1 браузеру в каждой. Если этого не делать, то, например, начинаются проблемы с пропаданием фокуса на окнах браузера.
На одной виртуальной машине живет только какая-то одна версия браузера (допустим там FireFox последней версии), так? И если нужен тест на более старой мажорной версии, то её нужно искать уже на другой ноде?
Selenium позволяет держать разные мажорные версии браузера на одной ноде, но с точки зрения администрирования делать так — одна большая проблема. Поэтому оказалось удобным ставить разные мажорные версии браузера на разные виртуальные машины: легче настраивать, легче переводить железо в браузеры и так далее. С точки зрения тестов ничего не меняется — указывается название браузера и версия, а gridrouter сам знает (это прописано в XML конфигурации) на какую машину пойти, чтобы отдать нужный браузер.
А под linux что-то другое были попытки использовать?
Например? Поскольку мы запускаем все на серверах без монитора, то xvfb — напрашивающееся решение. Обычный X сервер требует наличия монитора.
Уважаемый, пока ещё, Яндекс! А вы расскажете, как на свет вывалился гениальный продукт — обновленный интерфейс Кинопоиска?
К сожалению, я не владею информацией по данному вопросу, но уверен, что реакция последует.
Адекватную систему рейтингов верните
Извините за долгий ответ. Мы используем Gridrouter с OS X аналогично остальным браузерам, только вместо стандартной Selenium ноды используем Appium и Xcode, который тащит за собой нужные симуляторы и SDK. К сожалению по лицензионным соображениям нельзя устанавливать MacOS не на виртуальные машины в облаке, только на железки, на каждую из которых можно поставить не больше 2 параллельно работающих операционных систем. Это сильно ограничивает масштабирование решения.
Sign up to leave a comment.