Comments 22
Ответ: мы использовали все стенды по максимуму, под шум (крики) продуктовых команд! :)
Ну вы еще скажите, что никогда-никогда такого не было! ;)
(кроме "совсем уж" продакшена, куда не знаю как сейчас, а раньше вас (в смысле, сотрудников вашей конторы) непосредственно пускали не ко всему... хотя, в последние несколько лет наверняка что-то изменилось, конечно)
А можно просто купить DDOS на себя и пытаться выжить)
Можно предположить, что вся команда отлично знает базы данных. Так как поддерживает механизм подчистки. Мой опыт такой, что поддерживать такие скрипты можно, но для отдельных микросервисов. А для всех сервисов - сложно
Другое предположение, что основные сценарии только на чтение и ничего не создают. Это интересная мысль. Пробовали в команде такое сделать однажды, но для функциональных автоматических тестов, которые ничего не создают, а проверяют, что стенд работает.
Тут 2 темы, которые +/- работают у нас:
На тестовых средах - авто-рефреш объектов из бэкапов состояния "на вчера", а затем сверху накат тестовых данных (учёток, заявлений каких-нибудь и т.п.). Если вдруг тестирование перетекает на следующий день - временно отключить авто-рефреш (главное не забыть отключить и потом включить, но специально обученные люди следят за этим)
Про очистку данных после тестов просто когда пишешь скрипт - ты должен написать очистку данных для него ) что-то посложнее (удаление учетных записей, разная инфа о которых хранится в 20-30+ таблицах) - тут уже тикет на разработку, но полезно может быть и для Прода тоже может быть для очистки от мусора, т.е. скрипты не только для НТ )
Что выступает агентом мониторинга, который кладет данные в Clickhouse?
Используется отправка JSON через Kafka или Graphite-интерфейс или HTTP-протокол ClickHouse?
Или это какая-то интеграция с Prometheus, Victoria, InfluxDB перекладывает метрики в ClickHouse?
У нас попроще )
Парсер логов на java, который читает файлик гатлинга и пишет в Clickhouse, используем библиотеку от Яндекса (ru.yandex.clickhouse).
Парсер запускается в докере перед запуском каждого теста и вырубается после его окончания.
а парсер свой мониторите? в целом какой выдает оверхед по компонентам?
я так понимаю он же у вас на каждом из интансов крутится или для логов волюм на уловном гластере сделали?
Осуществляете ли вы при таком решении мониторинг парсера?
И замеряете ли overhead по утилизации хостов при таком решении?
Осуществляете ли вы при таком решении мониторинг парсера?
Не вызывал проблем, так что только по логам, если вдруг
И замеряете ли overhead по утилизации хостов при таком решении?
Хм.. Это не замеряли отдельно, в целом у нас мощность генераторов нагрузки средняя (8/8), составляет малый процент от мощностей нагружаемых систем. Такой генератор на Gatling выдаёт тысячи tps на простых запросах — нам хватает и не требует оптимизации.
UAT – отсюда можно стартовать регрессионное НТ
эм, что простите?) вы даже сами пишете про слабое железо на юатах, а потом выдаете такой дикий антипатерн.
Мониторинг в Grafana + Clickhouse
Для мониторинга генераторов нагрузки — Prometheus
никогда не понимал, зачем плодить винегрет из разных систем для мониторинга, да еще и с парсером логов инструмента нагрузки. Prometheus один не пробовали оставить или листенер под гатлинг завести не получилось?
Проверка стабильной нагрузки — короткий тест с заданным tps
точно нет очепятки?) стабильность и короткий тест в одном предложении, ну такое =)
вы даже сами пишете про слабое железо на юатах, а потом выдаете такой дикий антипатерн.
Для регрессионного тестирования вполне себе подходит, для начала, а что делать когда начинаешь НТ, а отдельного стенда нет?) Можно не всем профилем нагрузки тестировать сразу, а разбить на несколько частей (чтобы стенд выдержал). Я не говорю, что это — супер, но лучше, чем ничего ) Особенно когда НТ как процесс только стартует в компании.
зачем плодить винегрет из разных систем для мониторинга, да еще и с парсером логов инструмента нагрузки. Prometheus один не пробовали оставить или листенер под гатлинг завести не получилось?
В целом — согласен, наверное на prometheus по всем онлайн-метрикам можно было бы перейти, пока мы в процессе, да и более приоритетные задачи по автоматизации/мониторингу есть. А Clickhouse быстрее работает чем InfluxDB, некоторое время назад перешли (хоть цели могут быть и разные у этих БД — нам понравилось, так и остались).
стабильность и короткий тест в одном предложении
Стабильность не как "Надежность" - здесь речь о не изменении подаваемой нагрузки во время теста, т.е. стабильная ступень нагрузки, "ровная полка"
Для регрессионного тестирования вполне себе подходит, для начала, а что делать когда начинаешь НТ, а отдельного стенда нет?)
по хорошему? отладить сценарии чисто функционально и больше ничего, ибо это мартышкин труд кмк. Вот к примеру, у меня стенд сейчас под интеграцию, отличия от юата по железу раз в 40 на вскидку и что я должен гонять в таком варианте на юате? правильно, ничего =)
наверное на prometheus по всем онлайн-метрикам можно было бы перейти
мне кажется изначально было бы быстрее прикрутить листенер, чем реализовывать парсер логов.
Clickhouse быстрее работает чем InfluxDB
для меня инфлюкс умер уже года 4 как назад и производительность его одна из причин.
Стабильность не как "Надежность"
тогда мне кажется стоит это дописать, так как стабильность в части терминологии зачастую приравнивается к надежности.
отличия от юата по железу раз в 40 на вскидку и что я должен гонять в таком варианте на юате? правильно, ничего
+
тут не спорю, отличия в разумных пределах, конечно же. до "/10" стенда — можно нагружать
а как это потом транслировать в реальность по результатам? мы же все понимаем, что идеальная масштабируемость миф, точно воспроизводимая линейная встречается тоже не часто (даже простое скалирование под со стейтлес прикладами, линейность гарантированно дать не может) и по большей части масштабируемость будет не линейной.
а как быть с базами в части данных? ни ФТ, ни ЮАТ контур не имеет копии с прода, даже наполнения синтетикой нет (и сделать ее как правило не получится ибо дорого), а значит в этой части результаты будут вообще не релевантны.
а как это потом транслировать в реальность по результатам? .. даже простое скалирование под со стейтлес прикладами, линейность гарантированно дать не может
Конечно, об этом и пишу в статье в том числе, даже график приложил ) НО! в регрессе стабильной небольшой нагрузкой можно вылавливать баги. 1 изменение за раз - провёл эталон на текущем релизе, поставил новый релиз, провел регресс. Есть изменения по времени отклика / утилизации ресурсов / непонятные всплески tps / их падение - вот уже и есть наводка на вопросы и изучение. Опять же - лучше чем ничего, пускай качественного результата будет меньше, но уже - что-то
а как быть с базами в части данных? ни ФТ, ни ЮАТ контур не имеет копии с прода
Здесь по-разному, в основном конечно пользы маловато будет, не спорю.
Конечно, об этом и пишу в статье в том числе, даже график приложил )
пишите, вот только итоговый вывод противоречит патернам НТ)
в регрессе стабильной небольшой нагрузкой можно вылавливать баги
можно, как и вылавливать их при стрельбе в коленку, но это повод проводить такое НТ?). То о чем вы говорите, является по сути регрессионными смоук тестами, которые хорошо бы страивать в пайп деплоя на равне с юнитам и первичный анализ отдать разработчикам. Иначе придется самим следить за консистентностью еще и юата по конфигам и остальным прелестям, вплоть то настроек хостов на уровне ядра которые там всегда в дефолте.
вот уже и есть наводка на вопросы и изучение
да, действительно, вот только очень большой шанс того, что вы просто наткнетесь на разность конфигов, версий каких либо компонентов или просто по нагрузке на саму стойку, при условной переподписке на юате 1/20
только не подумайте, ничего личного, видимо уже проф деградация и меня тригерит от таких вот условностей)
просто вы взялись обучать молодых специалистов нашему очень не легкому ремеслу, потому хотелось бы, что бы это было максимально объемно и правильно, иначе та же фраза про ЮАТ будет многими воспринята как нормальность, а не исключение когда совсем уж все плохо, и потом людей придется переучивать.
наша профессия все же не скрипты писать, да кнопку запуска теста нажимать, чему увы и учат почти все курсы....а разбираться в устройстве систем, от железа до различного софта и чем глубже, тем лучше...ну и анализировать, анализировать, анализировать...от архитектур до результатов тестов)
Я за быстрый результат, но понимаю ваши опасения)
Бывает такое, что НТ так и остаётся чем-то незначительным и дальше какого-нибудь контура для ФТ и не уезжает.. Но, это в том числе хороший полигон, чтобы начать изучать систему, писать те самые первые скрипты и сценарии, погружаться в архитектуру — чем ждать условный год закупку отдельного стенда. Польза есть в общем, не надо её недооценивать ;)
Про курс — поддерживаю, что не только скрипты и кнопку нажимать. Не хотел рекламироваться, но сначала почитай мою программу да отзывы поспрашивай, если интересно ;)
https://otus.ru/lessons/loadqa/
На сим предлагаю тред завершить )
остаётся чем-то незначительным
тогда это нельзя называть полноценным нт)
да отзывы поспрашивай, если интересно ;)
я знаком с этим курсом, не один кандидат его прошедший приходил ко мне на ТИ, но увы ни один так его пройти и не смог, может это конечно я такой токсичный, но все на анализе простой архитектурной схемы засыпались=)
Стенд для нагрузочного тестирования: от DEV до PROD