Масштабирование тестов до 150+ параллельных потоков

Используем для запуска и параллелизации тестов pytest+ xdist
Хотим масштабироваться до 150+ потоков, но уже сейчас на 70 потоках сталкиваюсь с тем что создание и запуск процессов(70 штук) занимает до 2-3 минут времени, для нас это становится ботл-неком.

Хотел поинтересоваться у сообщества, кто как решает проблему многопоточного запуска тестов в контексте питон стека.

а зачем вам 150 потоков? У вас есть такое мощное железо чтобы выдержать или кластер?

1 лайк

Кажется такую задачу лучше решать силами CI, и параллелить по агентам, если конечно у вас есть возможность держать штук 30-50 агентов для тестирования. И внутри можно в 3-5 потоков/процессов прогнать тесты.

1 лайк

Можно попробовать запускать тесты на AWS Lambda или Google Cloud Functions

Нихрена себе :slight_smile: . Вообще многопоточное автоматизированное тестирование это зло.

Почему же?

За двумя потоками неудобно глазами наблюдать :smiley:

4 лайка

Тема интересная - у меня много вопросов =)
А расскажите, что уже пробовали делать?
На какой машинке запустили 70 потоков? Железо мощнее пробовали?
А само приложение тупить не начинает, достаточно мощный кластер? Может чтобы прогон быстрее проходил, надо приложение ускорить? Или больше тестов на моках проводить?
Пробовали сравнивать pytest + xdist с nose, GitHub - mtreinish/stestr: A parallel Python test runner built around subunit или ещё чем-то?
Пытались другой интерпретатор прикрутить Cython, PyPy?
А сколько всего тестов, долго бегут? Почему так много? =)
На уровне CI пробовали отправлять разные куски тестового набора? Как результаты?
Может Python-стек не самый подходящий для дикой параллелизации? Выглядит так, что может ничего не взлететь из того, что перечислил, либо дать незначительный прирост и надо будет писать либо самом что-то на greenlet’ах либо переходить на что-то с более хорошей параллелизацией, типа golang =)

1 лайк

Из поставленного вопроса абсолютно непонятно, что же является узким местом: загрузка процессора достигает 100%, потребляемая память… - гадать можно бесконечно.
Вот хороший пример обнаружения проблемы и ее решения:
http://spirogov.github.io/kak-ia-liechil-py-test-fikstury-dlia-xdist/

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

Да, сейчас один из вариантов который хочется опробовать это паралелить запускаемые тесты по агентам на уровне пайплайна CI. Для этого правда понадобится модифицировать принцип запуска тестов, но это решаемо.

Хотелось послушать как подобные вещи решают коллеги по цеху.

Облачные решения для нас дороговаты, хочется все таки соблюсти баланс цена\качество на приемлемом уровне.

Сейчас запускаем в 100 потоков на дженкинс агенте, который живет на железке с 22 гигами оперативки и 24 процессорами.

В момент спавна процессов xdist все процессоры в полке, и собственно ботлнек походу тут.
Т.е в данный момент у нас порядка 600 тестов, и насколько я понимаю в момент старта процесса xdist берет весь набор тестов для каждой из дочерних нод, выполняет какие то приготовления, фильтрации и так для каждой из 100. В данный момент он делает это в течении приблизительно одной минуты для 100 потоков. И логично предположить что для 300 потоков он будет делать это порядка 3 минут.

Например 100 тестов в 100 потоков выполняются ~4 минуты, и на этом фоне стартовать в течении 1 минуты довольно больно, хочется это место оптимизировать.

Мы очень сильно завязались на pytest изза того что пишем свои обвязки и плагины, являющиеся частью управляющей тестами инфраструктуры, и по этому в данный момент в поисках воркэраунда в контексте pytest.

Приложение такую нагрузку выдерживает без проблем, и мы будем дальше наращивать количество потоков и самих тестов.

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

Ну у той же лямбды - миллион вызовов в месяц бесплатно. А если есть железо - можно реализовать с каким то GitHub - vmware-archive/kubeless: Kubernetes Native Serverless Framework

А потом один вызов удаленной функции - будет выполнять один конкретный тест. Максимального количества потоков теоретически не существует.

Я делал эксперименты по использованию AWS лямбд в тестировании, у меня доклад на селениум кемпе был.

Видео доклада в доступе уже?

Да, можешь поискать на youtube - Scaling execution of ProtractorJS on AWS Lambda with Selenoid