Как вы проводите нагрузочные тесты моделирующие реальную нагрузку на production?



ЗдравствуйтеПодскажите, пожалуйста, как вы проводите нагрузочные тесты моделирующие реальную нагрузку на production? Есть какие-то инструменты?У нас сейчас есть тест, написанный с использованием JMeter. Мы его начали писать и прогонять ещё до выхода в live. На production видим, что профиль нагрузки отличается. Вручную менять тест выглядит не очень продуктивным занятием. Хочется что-то вида "записали журнал запросов на prod, отмасштабировали, проиграли на тестовом стеке". Полностью автоматически всё равно не получится, в запросах же ID везде. Но как облегчить задачу создания такого теста? Что почитать?
581   33  

Comments

  1. Роман Ивлиев
    Роман Ивлиев 5 лет назад
    https://jmeter.apache.org/.../jmeter_proxy_step_by_step.html И его же компоненты для дата-дривен тестов
  2. Artem Nikitin
    Artem Nikitin 5 лет назад
    Яндекс Танк умеет генерить нагрузку на основании access.log от nginx
    • Timur Hairullin
      Timur Hairullin 5 лет назад
      Да, это самое очевидное решение. Только загвоздка в том, что этим логом потом надо будет стрелять в продакшн (или в модель продакшна в масштабе 1:1)Основная задача-то как раз состоит в том, чтобы соотнести мощность тестового кластера и профиль нагрузки, который мы на него подаём
    • Илья Ширшов
      Илья Ширшов 5 лет назад
      Timur Hairullin нафильтровать можно этот аксес лог по-разному жеж.
    • Евгений Степченко
      Евгений Степченко 5 лет назад
      Спасибо, что-то я про него не вспомнил даже в своих поисках и гугл не подсказал.
  3. Timur Hairullin
    Timur Hairullin 5 лет назад
    Я бы посоветовал в такой ситуации как следует разобрать типичные сценарии нагрузки на продакшне, покурив логи и попредставляв всякое, и на основании познанного написал бы несколько разных тестов. Каждый эмулирует типичный сценарий (пятница; хабраэффект; распродажа; вышла реклама в телевизоре – не знаю, что у вас за проект и какие там будут специальные случаи). А ещё свёл бы синтетический тест на основе профиля нагрузки в продакшне. И перед запуском прогонял бы все эти тесты, смотря на регрессионные показатели, то есть сравнивая с предыдущим прогоном.Для этого надо будет наготовить тестовых данных, адекватных продакшну, и под них уже сдедать тесты, принимая во внимание разницу в мощности продакшна и тестового кластера.
    • Роман Ивлиев
      Роман Ивлиев 5 лет назад
      и дубасить прод в моменты, когда нагрузка на него минимальная, реальные показатели только на целевом оборудовании.
    • Timur Hairullin
      Timur Hairullin 5 лет назад
      Роман Ивлиев чревато спецэффектами. В один прекрасный момент пользователи одной там платёжной системы с удивлением обнаружили у себя в истории платежи на одну копейку, которых они не совершали ;))
    • Роман Ивлиев
      Роман Ивлиев 5 лет назад
      Ну так с головой же надо, ага:)
    • Павел Сидорович
      Павел Сидорович 5 лет назад
      Timur Hairullin шта? как потом наказывали за такой дыркокод?
    • Евгений Степченко
      Евгений Степченко 5 лет назад
      Возможно, этот вариант даст наиболее качественный тест, но он же и наиболее трудоёмкий.
  4. Eugene Klimov
    Eugene Klimov 5 лет назад
    лично я в итоге пришел к скрипту на python который по умному парсит логи nginx и дальше генерит стабы для комплексного функционального теста на http://locust.io + https://github.com/myzhan/boomer/
  5. Андрей Шорин
    Андрей Шорин 5 лет назад
    Если вы хотите понять, как изменилась производительность какого-то компонента/микросервиса, то точное воспроизведение прода, будь то 1:1 или в масштабе вам не нужно.
    • Timur Hairullin
      Timur Hairullin 5 лет назад
      Мониторинг – это второй по дороговизне способ узнавать о критической проблеме. Хорошо бы, чтобы наши нагрузочные тесты выявили эту проблему раньше, чем продакшн. Дальше повторить ваш второй абзац к тестовому кластеру – и всё будет прекрасно
    • Андрей Шорин
      Андрей Шорин 5 лет назад
      Timur Hairullin чтобы не только куда-то двигаться, а двигаться к цели и суметь понять, насколько удалось её достичь, хорошо бы знать, а где мы находимся. Причем здорово выразить текущее состояние в измеримых величинах. Ага, я говорю про мониторинг.
    • Timur Hairullin
      Timur Hairullin 5 лет назад
      Andrey Shorin С которым из Евгениев в этом треде? (я вообще кадровик, игнорируйте меня ;))С постановкой вопроса про уточнение задачи, тем не менее, согласен.
    • Андрей Шорин
      Андрей Шорин 5 лет назад
      Timur Hairullin я такой вопрос задал потому, что Вы активно отвечаете на комментарии, обращённые к автору поста. При этом у меня создалось впечатление, что Вы выступаете с позиции, в которой знаете его боль или имеете достаточно подробностей чтобы оценить, что для него важно.
    • Timur Hairullin
      Timur Hairullin 5 лет назад
      Andrey Shorin А, в этом смысле. Ну, я немножко занимался нагрузочным тестированием в прошлом, и предполагаю, что проблемы Евгения мне знакомы. Но с Евгением мы никак не связаны и не пересекались.
    • Евгений Степченко
      Евгений Степченко 5 лет назад
      Андрей Шорин (Andrey Shorin)
    • Андрей Шорин
      Андрей Шорин 5 лет назад
      Евгений Степченко по 1) написал. Если компоненты по одной тестировать, то масштаб можно похерить.
    • Андрей Шорин
      Андрей Шорин 5 лет назад
      Евгений Степченко 2) это про то, сколько ещё можно тянуть с закупкой оборудования?
    • Евгений Степченко
      Евгений Степченко 5 лет назад
      Андрей Шорин Ок, на проде не будем
    • Андрей Шорин
      Андрей Шорин 5 лет назад
      Евгений Степченко версии у компонентов ведь не в один момент меняются. Поэтому каждую проверить отдельно вполне получится. В автотесты добавить нужный сценарий очень даже можно. Сравнивать показатели отклика предыдущей версии и новой будет достаточно
    • Евгений Степченко
      Евгений Степченко 5 лет назад
      2 - нет, мы пока в облаке и с автоскейлингом. Не проблема быстро расшириться.
    • Андрей Шорин
      Андрей Шорин 5 лет назад
      Если монолит, то организовать такие подрелизы будет несколько сложнее...
    • Андрей Шорин
      Андрей Шорин 5 лет назад
      Евгений Степченко если мысли появились, то пора шардить Я почти серьёзно.
    • Евгений Степченко
      Евгений Степченко 5 лет назад
      Как раз не монолит и, мне кажется, с задачей написания вручную сценариев тестов для всех отдельных сервисов мы точно не справимся. Это на порядок больше сценариев, чем чисто пользовательских.
    • Евгений Степченко
      Евгений Степченко 5 лет назад
      Не, пока у нас запас большой от текущей нагрузки. Ещё единая база справляется (есть узкие места, но банальной оптимизацией ещё долго можно спасаться).
    • Андрей Шорин
      Андрей Шорин 5 лет назад
      Евгений Степченко у меня появился вопрос к качеству мониторинга. Насколько ему удается показывать, где именно узкое место?
  6. Алексей Никулин
    Алексей Никулин 5 лет назад
    поведение продакшена всегда (имхо) будет отличаться от тестовой нагрузки. нагружать продакшен (так же как и тестировать его) - идея не очень хорошая по многим причинам.
    • Евгений Степченко
      Евгений Степченко 5 лет назад
      Вот от реализации всех сценариев полностью в ручную и хотелось бы уйти. Хотя бы частично. Плюс реальные пользователи подбрасывают сюрпризы.
    • Алексей Никулин
      Алексей Никулин 5 лет назад
      Пользователи не подбрасывают сюрпризы за пределами вашей модели нагрузки. Её и надо тестировать. Если же взять тупо трафик с продакшена, это будет в лучшем случае средняя температура по больнице - полезно, но без откровений.
    • Евгений Степченко
      Евгений Степченко 5 лет назад
      Не понял. Уточните, пожалуйста, что вы называете "моделью нагрузки" и почему пользователи обязательно ей следуют.