По делу: CPU Limits - не гарантируемая область процессорного времени контейнеру, которая ограничивает приложения. Не будет ли правильнее оперировать именно CPU Requests в GOMAXPROCS. Иными словами во время ресурсно голодания на ноде ваши сервисы будут работать неэффективно, потому что затортлятся до реквестов.
статья огонь! caretta показала себя не очень хорошо на больших кластерах, больше 3500 под. периодически показывает абсолютно невозможные связи с низким уровнем трафика и при старте не кисло ддосит кубовый аписервер.
Ребята, спасибо вам за статью. Это многим даст понять, что ошибаются все и важнее не заниматься охотой на ведьм, а делать вывод.
Но сказать в первую очередь я хотел о выводах относительного нагрузочных тестов и практик перфоманса. У меня тут жирный опыт и коротко могу сказать вот о чем:
привлекать разработку к перформанс тестам это полезно, часто даже интересно самой разработке, а главное это приносит пользу. но сильно зависит от вовлечённости
вбухивать кучу денег в перф инженеров, пытаться держать окружение для перф тестов 1в1 как прод и делать "суперреалистичные" нагрузочные тесты - миф. прод такой один и тоже самое сделать не выйдет, суперреалистичные тесты бесконечно дорогие - вы придете к тому что будете трейдоффить относительно параметризации и скорости тестирования, например, ну а куча перф инженеров должны будут сначала как-то сделать единый фреймворк и потом уже что-то тестить с каким-то качеством тестов. вот у меня есть статья как раз про подходы https://habr.com/ru/company/oleg-bunin/blog/682746/
я бы на вашем месте выстраивал фреймворки для перформанс тестирования продакшена. теневые инстансты, зеркалирование траффика, грейсфул деградейшн. и тут куча бонусов, чтобы тестировать прод надо сделать его отказоустойчивым, а трафик управляемым - это раз. если вы боитесь падений вы делаете фолбэки и фичатоглы - это два. прод есть прод и его не надо пытаться повторить со всеми его сайдэффектами и уникальным железом - это три. ну и бонусный трек - испытания на проде дадут вам такой же профит как инцидент, только это будут контролируемые и подготовленные условия (осторожно - тоже можно прилечь на 4 часика, но оно того стоит :))
Это очень хороший подход, но только это уже ближе к SRE. Мы развиваемся в похожей модели, но в ней пока главная роль у перф тестов, где не помимо QG есть ещё много всего. Наша концептуальная модель - мы овнеры проблем производительности и отказоустойчивости начиная с архитектурных комитетов, создания конвеншнов и поддержкой тестового воркэраунда, заканчивая тестами в проде, хаос инжинирингом и инцидент менеджментом. Постепенно на главную роль выходит бюджет ошибок.
И да, мы тоже чаще всего идём сейчас в максимально простые тесты лишь бы не было проблем. И вот основная комплексность появляется как раз там где что-то идёт не так: сразу задумываешься, а это тесты плохие или реально проблема есть, потом ударяешься в параметризацию, распределения, а проблема все есть и так постепенно обрастаешь толстыми сложными тестами.
Если не ударяться в разработку своего инструментария, попробовать заранее решить потенциальные проблемы с инфой, то думаю можно за месяц успеть
В рамках того подхода, что я описываю в статье есть на самом деле очень понятный конвеншн - мы хотим быть ближе к пользовательскому трафику настолько, чтобы нагрузка приносила пользу, но сами тесты не требовали космических затрат по времени. И тут мы делим подход к таким запросам на три этапа, каждый из которых повышает трудозатраты. На каждом из этапов мы можем принять решение исключить запрос из QG и делать на него отдельные тесты, которые нам будут понижать риски (вне QG у нас есть много практик):
Мы просто ориентируемся на то что считает правильным разработчик, плюс можем помочь принять ему решение проведя маленькое ревью логов и их времени выполнение запроса относительно набора параметров. Результатом будет грязная и быстрая параметризация, которая в целом нас устраивает какое-то время.
Далее мы с помощью любых наших практик, например QG скажет что расхождение с продом очень высокое или мы увидим на алертах что этот запрос стреляет в 99 персентилей по 15 сек. Мы можем сделать довольно просто - можем провести анализ на "полезные" свойства (возвращаясь к property based testing) или на "тяжелые" и тестировать только близкий к плохому сценарий. В этом случае мы точно знаем, что пользователь не будет всегда ходить по тяжелым кейсам и если наша система выдержит нагрузку ими, то любые лёгкие кейсы ей вообще не составит труда. Есть вариант, когда подмешиваем простые кейсы в нагр. Баланс тут зависит от того, что реально держит система и что должна держать. Но ключевым является парадигма, что тяжелых запросов должно быть больше чем на продуктиве.
Если все равно получаем сигналы о больших расхождениях или другими путями понимаем, что нагрузка непоказательна. Тогда мы можем сделать 2 варианта: а) собирать распределение динамически с прода в каждом тесте - это может быть анализ логов, метрик, даже распределение по времени например; б) собрать распределение разово и делать запросы на основе него. у первого варианта понятное ограничение - воспроизводимость. у второго тоже - актуальность. обычно на выбор влияет источник данных, например мы не можем сходить из теста за самым актуальным распределением в продовую базу, а например в ELK можем. Распределение можно представить в виде CSV, но тогда нужно много данных чтобы обеспечить сходимость или в виде мапы с шансом и значениями, она может быть с просто с уникальным набором ключей.
И вопрос чему учить : просто знания в голове или прикладной инструмент. Другими словами не надо знать всех премудростей моделей нагрузки, детектинга перф проблем, мониторинга и тд, надо просто уметь кинуть несколько запросов в систему и для этого есть гайд, шаблон и команда помощи - все остальное сделается само :)
Скорее тут вопрос кого учить, если мы учим нагрузочных инженеров быть крутыми - это дорого, долго и сложно, а выхлоп может быть никакой. А если мы предоставляем инструмент продуктовым командам (не важна роль), даём простые гайды, и максимальное обучение это небольшой воркшоп то знания не несут такой ценности и не такие хрупкие.
Большое спасибо за статью. Расскажите как у вас внутри пайплана умещается проведение НТ. Для показательных тестов надо развернуть , иногда, толстую базу - она проливается каким-то данными? Сами тесты на чем реализованы и кто их поддерживает?
Мы делаем нечто подобное в формате load as a service для команд разработки, хотел бы узнать о вашем опыте :)
Есть много вопросов и комментариев, по большей части по тому что я довольно давно пропагандирую подобный подход и радует, что вы уже в начале пути.
Комментарии:
Кажется, что сервисная история должна упрощать процессы и снижать бюрократизацию, судя по набору требований из таска к вашей команде там у команды появляется очень не сервисная активность в виде сбора и формализации кучи вещей, которые ещё и вероятно будут заставлять их заниматься уточняющей коммуникацией. Мы ходили по такой модели, лучший вариант - это ввести практики которые бы собирали за них весь этот набор или давали бы его в полуготовом виде.
Сами UI-ые скрипты JMeter, конечно имеют преимущество над кодовыми решениями, но степень их поддерживаемости, переиспользуемости и прочих благ очень слабая. Чем больше вариантов каждого теста, чем больше продуктов это становится все сложнее. Нужно поменять креды юзера везде? Нашёл скрипт, открыл на локалке, поменял, закрыл, сохранил, залил. И так с каждым. С аналогичной проблемой сталкивались и мы, тут могу порекомендовать уехать на jmeter-java-dsl если хотите jmeter.
Вопросы:
Почему вы записываете сценарии а не нагружаете апишку в соответствии с тем количеством рпс которое приближено к проду. И если у вас сценарный подход то как вы матчите рпсы с прода и сценарии?
Почему бы не тестировать каждый релиз и каждый сервис, вместо того чтобы рождать сущности в виде регламентом и устраивать охоту на ведьм когда кто-то идёт мимо него?
А кто валидирует результаты тестов и ищет перформанс проблемы? Этому научить например функционального тестера очень ресурсоемко, а если заниматься этим самостоятельно то получиться что при большом количестве релизов вы будете постоянно находится в этом анализе. Мы эту проблему решили собственным анализатором результатов (Quality Gate) который не пустит в прод если есть проблема и сам ее максимально подсветит, чтобы была возможность команде ее самостоятельно решить.
Почему тесты идут с минимумом заглушек? Если надо запустить 2 теста параллельно они ждут когда стенд освободиться? Если это блокирует релиз то это очень негативное влияние на тайм ту маркет
Очень ещё интересно, а много вообще желающих этому обучаться внутри команд?
Если могу помочь - приходи, телегу знаешь)
В целом очень круто, выглядит как набор правильных решений на старте, а чтобы не было больно потом я надеюсь помогут комменты выше)
Пользуюсь активно этим DSL, пишем для него обёртки и контрибьютим в него. У DSL комьюнити появился дискорд для обсуждения насущного. Залетайте по ссылке в гитхабе
Какими инструментами пользуетесь для подачи нагрузки? Если Танк, то не совсем технически понятно, как подложить в него access-лог. Можете детализировать немного? А так, крутой подход, к которому стоит стремиться, может не полностью, но идея с продакшен НТ — очень занимательная.
Хорошая статья, все лаконично описано. Хотел бы привлечь внимание к моменту имитации реальных пользователей. Стоит сказать, что реально имитировать действия пользователей просто паузами — недостаточно. Там много всяких нюансов начиная от невозможности воспроизвести реальный партерн их поведения, заканчивая куками, спецификой браузеров и операционок. Все это — высокая стоимость НТ, которая дает низкий профит. Если виртуальные пользователи будут вести себя один в один как реальные, для имитации, например десятысечной аудитории вам потребуется либо одна очень хорошая машина, либо несколько, но похуже, 10к потоков, с большим количеством логики и параметризации, которые не редко приводят к утечке памяти на генераторах. Хорошая практика — исследование поведения и сценариев реального влияния на нагрузку системы. Допустим, если для системы однобоко количество коннектов — можно реализовать нагрузку 10к пользователей сотней суперпроизводительных. Если системе не важно, что придет в параметре, то и параметризировать его нужно в зависимости от важных показателей — в случае если параметр пишется в БД как коммент, например, можно пренебречь его семантикой и генерить рандомно — проще, а главное дешевле. В погоне за «реальными пользователями» заказчики платят дорого, а нагрузочники страдают от задач, связанных с утилизацией ресурсов, оптимизацией скриптов, написанием трушных генераторов и прочий околоНТшный треш. В большинстве своем веб тестируется тпсами/сценариями, которые параметризованны в соответствии с рисками кэширования и распределениями в БД — минимально. Таким образом дешево, легко поддерживается, быстро и легко пишется — а результаты в сравнении с мучениями относительно тру юзеров, чаще всего, аналогичны.
Статья огонь, у нас было похоже исследование по JVM https://habr.com/ru/companies/samokat_tech/articles/735638/ и мы тоже наследуем эффективный параллелизм контейнера в параметры жавы.
По делу: CPU Limits - не гарантируемая область процессорного времени контейнеру, которая ограничивает приложения. Не будет ли правильнее оперировать именно CPU Requests в GOMAXPROCS. Иными словами во время ресурсно голодания на ноде ваши сервисы будут работать неэффективно, потому что затортлятся до реквестов.
статья огонь! caretta показала себя не очень хорошо на больших кластерах, больше 3500 под. периодически показывает абсолютно невозможные связи с низким уровнем трафика и при старте не кисло ддосит кубовый аписервер.
Отчеты с скринами из графаны без вебдрайвера и подобной боли:
https://github.com/kirillyu/jmeterReports
https://github.com/kirillyu/jmeterReports2
Ребята, спасибо вам за статью. Это многим даст понять, что ошибаются все и важнее не заниматься охотой на ведьм, а делать вывод.
Но сказать в первую очередь я хотел о выводах относительного нагрузочных тестов и практик перфоманса. У меня тут жирный опыт и коротко могу сказать вот о чем:
привлекать разработку к перформанс тестам это полезно, часто даже интересно самой разработке, а главное это приносит пользу. но сильно зависит от вовлечённости
вбухивать кучу денег в перф инженеров, пытаться держать окружение для перф тестов 1в1 как прод и делать "суперреалистичные" нагрузочные тесты - миф. прод такой один и тоже самое сделать не выйдет, суперреалистичные тесты бесконечно дорогие - вы придете к тому что будете трейдоффить относительно параметризации и скорости тестирования, например, ну а куча перф инженеров должны будут сначала как-то сделать единый фреймворк и потом уже что-то тестить с каким-то качеством тестов. вот у меня есть статья как раз про подходы https://habr.com/ru/company/oleg-bunin/blog/682746/
я бы на вашем месте выстраивал фреймворки для перформанс тестирования продакшена. теневые инстансты, зеркалирование траффика, грейсфул деградейшн. и тут куча бонусов, чтобы тестировать прод надо сделать его отказоустойчивым, а трафик управляемым - это раз. если вы боитесь падений вы делаете фолбэки и фичатоглы - это два. прод есть прод и его не надо пытаться повторить со всеми его сайдэффектами и уникальным железом - это три. ну и бонусный трек - испытания на проде дадут вам такой же профит как инцидент, только это будут контролируемые и подготовленные условия (осторожно - тоже можно прилечь на 4 часика, но оно того стоит :))
Хороших стрельб
Молодцы! Я бы только порекомендовал не поддерживать самописные велосипеды, а юзать хороший опенсорс https://github.com/abstracta/jmeter-java-dsl
Хороших стрельб!
Это очень хороший подход, но только это уже ближе к SRE. Мы развиваемся в похожей модели, но в ней пока главная роль у перф тестов, где не помимо QG есть ещё много всего. Наша концептуальная модель - мы овнеры проблем производительности и отказоустойчивости начиная с архитектурных комитетов, создания конвеншнов и поддержкой тестового воркэраунда, заканчивая тестами в проде, хаос инжинирингом и инцидент менеджментом. Постепенно на главную роль выходит бюджет ошибок.
И да, мы тоже чаще всего идём сейчас в максимально простые тесты лишь бы не было проблем. И вот основная комплексность появляется как раз там где что-то идёт не так: сразу задумываешься, а это тесты плохие или реально проблема есть, потом ударяешься в параметризацию, распределения, а проблема все есть и так постепенно обрастаешь толстыми сложными тестами.
Если не ударяться в разработку своего инструментария, попробовать заранее решить потенциальные проблемы с инфой, то думаю можно за месяц успеть
Отличный вопрос и очень дорогостоящий :)
В рамках того подхода, что я описываю в статье есть на самом деле очень понятный конвеншн - мы хотим быть ближе к пользовательскому трафику настолько, чтобы нагрузка приносила пользу, но сами тесты не требовали космических затрат по времени. И тут мы делим подход к таким запросам на три этапа, каждый из которых повышает трудозатраты. На каждом из этапов мы можем принять решение исключить запрос из QG и делать на него отдельные тесты, которые нам будут понижать риски (вне QG у нас есть много практик):
Мы просто ориентируемся на то что считает правильным разработчик, плюс можем помочь принять ему решение проведя маленькое ревью логов и их времени выполнение запроса относительно набора параметров. Результатом будет грязная и быстрая параметризация, которая в целом нас устраивает какое-то время.
Далее мы с помощью любых наших практик, например QG скажет что расхождение с продом очень высокое или мы увидим на алертах что этот запрос стреляет в 99 персентилей по 15 сек. Мы можем сделать довольно просто - можем провести анализ на "полезные" свойства (возвращаясь к property based testing) или на "тяжелые" и тестировать только близкий к плохому сценарий. В этом случае мы точно знаем, что пользователь не будет всегда ходить по тяжелым кейсам и если наша система выдержит нагрузку ими, то любые лёгкие кейсы ей вообще не составит труда. Есть вариант, когда подмешиваем простые кейсы в нагр. Баланс тут зависит от того, что реально держит система и что должна держать. Но ключевым является парадигма, что тяжелых запросов должно быть больше чем на продуктиве.
Если все равно получаем сигналы о больших расхождениях или другими путями понимаем, что нагрузка непоказательна. Тогда мы можем сделать 2 варианта: а) собирать распределение динамически с прода в каждом тесте - это может быть анализ логов, метрик, даже распределение по времени например; б) собрать распределение разово и делать запросы на основе него. у первого варианта понятное ограничение - воспроизводимость. у второго тоже - актуальность. обычно на выбор влияет источник данных, например мы не можем сходить из теста за самым актуальным распределением в продовую базу, а например в ELK можем. Распределение можно представить в виде CSV, но тогда нужно много данных чтобы обеспечить сходимость или в виде мапы с шансом и значениями, она может быть с просто с уникальным набором ключей.
И вопрос чему учить : просто знания в голове или прикладной инструмент. Другими словами не надо знать всех премудростей моделей нагрузки, детектинга перф проблем, мониторинга и тд, надо просто уметь кинуть несколько запросов в систему и для этого есть гайд, шаблон и команда помощи - все остальное сделается само :)
Скорее тут вопрос кого учить, если мы учим нагрузочных инженеров быть крутыми - это дорого, долго и сложно, а выхлоп может быть никакой. А если мы предоставляем инструмент продуктовым командам (не важна роль), даём простые гайды, и максимальное обучение это небольшой воркшоп то знания не несут такой ценности и не такие хрупкие.
Большое спасибо за статью. Расскажите как у вас внутри пайплана умещается проведение НТ. Для показательных тестов надо развернуть , иногда, толстую базу - она проливается каким-то данными? Сами тесты на чем реализованы и кто их поддерживает?
Мы делаем нечто подобное в формате load as a service для команд разработки, хотел бы узнать о вашем опыте :)
Есть много вопросов и комментариев, по большей части по тому что я довольно давно пропагандирую подобный подход и радует, что вы уже в начале пути.
Комментарии:
Кажется, что сервисная история должна упрощать процессы и снижать бюрократизацию, судя по набору требований из таска к вашей команде там у команды появляется очень не сервисная активность в виде сбора и формализации кучи вещей, которые ещё и вероятно будут заставлять их заниматься уточняющей коммуникацией. Мы ходили по такой модели, лучший вариант - это ввести практики которые бы собирали за них весь этот набор или давали бы его в полуготовом виде.
Сами UI-ые скрипты JMeter, конечно имеют преимущество над кодовыми решениями, но степень их поддерживаемости, переиспользуемости и прочих благ очень слабая. Чем больше вариантов каждого теста, чем больше продуктов это становится все сложнее. Нужно поменять креды юзера везде? Нашёл скрипт, открыл на локалке, поменял, закрыл, сохранил, залил. И так с каждым. С аналогичной проблемой сталкивались и мы, тут могу порекомендовать уехать на jmeter-java-dsl если хотите jmeter.
Вопросы:
Почему вы записываете сценарии а не нагружаете апишку в соответствии с тем количеством рпс которое приближено к проду. И если у вас сценарный подход то как вы матчите рпсы с прода и сценарии?
Почему бы не тестировать каждый релиз и каждый сервис, вместо того чтобы рождать сущности в виде регламентом и устраивать охоту на ведьм когда кто-то идёт мимо него?
А кто валидирует результаты тестов и ищет перформанс проблемы? Этому научить например функционального тестера очень ресурсоемко, а если заниматься этим самостоятельно то получиться что при большом количестве релизов вы будете постоянно находится в этом анализе. Мы эту проблему решили собственным анализатором результатов (Quality Gate) который не пустит в прод если есть проблема и сам ее максимально подсветит, чтобы была возможность команде ее самостоятельно решить.
Почему тесты идут с минимумом заглушек? Если надо запустить 2 теста параллельно они ждут когда стенд освободиться? Если это блокирует релиз то это очень негативное влияние на тайм ту маркет
Очень ещё интересно, а много вообще желающих этому обучаться внутри команд?
Если могу помочь - приходи, телегу знаешь)
В целом очень круто, выглядит как набор правильных решений на старте, а чтобы не было больно потом я надеюсь помогут комменты выше)
Пользуюсь активно этим DSL, пишем для него обёртки и контрибьютим в него. У DSL комьюнити появился дискорд для обсуждения насущного. Залетайте по ссылке в гитхабе
Очень поддерживаю, реалистичность — дорого и, чаще всего, не нужно
Уже давно нет проблем с памятью, даже на нагрузках в 1000 рпс, они остались на версиях ниже 5, по ощущениям
Какими инструментами пользуетесь для подачи нагрузки? Если Танк, то не совсем технически понятно, как подложить в него access-лог. Можете детализировать немного? А так, крутой подход, к которому стоит стремиться, может не полностью, но идея с продакшен НТ — очень занимательная.