Selenium: Технические требования при большой нагрузке

Возникла потребность в очень большом количестве функциональных тестов. Примерно около 60 порталов, постоянный прогон тестов (примерно около 5 тестов, зайти на страницу, потыкать кнопки), каждые 20 минут.

Так вот. Какое железо нужно для #selenium фермы ? Как я понимаю - это один хаб и несколько нод. Какое железо необходимо под ноды? Сколько необходимо нод? Или может необходимо больше #selenium хабов? Был ли у кого такой опыт? Как его решали?

p.s Пробовали уже внедрять кстати, но что-то совсем неудачно. Был один сервер и одна нода. Нода запущена на винде с 16 гб памяти, хорошим восьмиядерным процом. Все работало жутко ужасно, тормозило,браузеры не закрывались, росла память бесконечно. Проверялось все на 2.49. Чуть получше стало, когда перенесли кеш браузеров в память, но не сильно…

По-моему, ваша проблема не в железе, а в коде. Такой конфигурации хватит с головой (конечно если вы не запускаете тесты в параллели в пределах одной ноды).

Лично у нас все тесты ранятся независимо друг от друга (параллелим по нодам), с чистой сессией. Виртаулки под ноды: 8 Гб ОЗУ, Intel® Xeon® Processor E5-2670 v3. Полет нормальный, с учетом прокси и видео записи через ffmpeg.

Тесты запускались на одной ноде в паралели. Т.е несколько браузеров сразу. Как лучше разделить? 1 браузер, одна нода?

Браузеры нынче вредные, голодные к ресурсам. Запускать N браузеров в пределах 1 тачки - очень рискованный шаг. Даже на хорошем железе. Многое еще зависит от того, как вы работаете с многопоточностью. Вполне возможно, что описанные выше проблемы только лишь из-за этого и возникают.

Если ресурсы позволяют - лучше конечно разделять. Но при небольшом числе браузеров и отсутствии специфических требований (к примеру, видео запись, OCR и т.п.), можно и в пределах одной ноды запускать.

Хаб точно должен жить отдельно, дабы исключить падение всей инфраструктуры при, скажем, недоступности одного нода.

Прокси, CI и т.п., естественно тоже живут отдельно от нодов.

Стоит также обратить внимание на массовую пересылку тяжеловесного контента по сети (скриншоты, видео, har файлы и т.п.). Весь медиа контент желательно оставлять на нодах (если конечно вы их не разворачиваете динамически в облаках для отдельных запусков). В противном случае, рискуете резко увеличить total execution time + относительно быстро лишиться всего HDD space на Jenkins. В репорт, при этом, лучше атачить лишь линки с динамически подгружаемым контентом.

К слову, в следующем докладе были рассмотрены некоторые популярные проблемы при внедрении масштабирования:

Еще, с того же селениум кампа, рекомендую посмотреть про грид роутер:
http://seleniumcamp.com/talk/grid-router-scalable-and-fault-tolerant-solution-for-grid/

там тоже есть ответы на некоторые вопросы.