digital-garden/source/курсы/otus/Архитектор высоких нагрузок 2019/Нагрузочное тестирование.md
2024-06-13 21:01:37 +03:00

6.3 KiB
Raw Blame History

parents date zero-link
Архитектор высоких нагрузок - OTUS 2019
2024-01-28
00 Архитектура ПО

Интересные мысли

  • Отчеты по тестированию это чувствительные данные. Если отчеты попадут на в те руки, то они могут привести к подготовленной атаке на систему, что понесет за собой большие убытки. Поэтому отчеты по тестированию должны надежно храниться, и доступ к ним должен быть у ограниченного числа лиц.

На что чаще всего смотрят?

  • Быстрые ответы сервера
  • Эффективная утилизация ресурсов железа

Тестирование производительности

  • подсистемы серверов
    • оделировать нагрузку на диск: Flexible I/O Tester (fio).
    • оделировать нагрузку на процессор: Phoronix.
    • оделировать нагрузку на сеть: iperf3.
  • серверов и приложений на простых запросах
    • подать нагрузку на балансировщик
    • подать нагрузку на БД
    • подать нагрузку на сервер приложений
  • приложение при выполнении сценариев
  • в соответствии с требованиями

Статичные не связанные запросы к системе:

  • Заданное количество повторений
  • Один или несколько фиксированных запросов
  • Точечная простая нагрузка

Утилиты для статичных запросов:

  • BASH-скриптом с curl/wget в цикле
  • На уровне TCP-протокола - tcpreplay
  • На MySQL - sysbench
  • На PostgreSQL - pgbench
  • На балансировщик - httperf (с паузами по списку URL)
  • На сервер - Apache Benchmark

Динамически связанные запросы к системе

  • Высокая интенсивность, но неконтролируемая
  • Запросы, связанными в сценарий

Точная нагрузка по требованиям

  • В подходящее время и в нужном месте
  • С нужно нагрузкой
  • С анализом происходящего

Утилиты для точной нагрузки:

  • Jmeter - простые сценарии (Groovy, Java, JavaScript)
  • Gatling - сложные сценарии с десятками запросов (Scala)
  • wrk - автоматизация на Lua
  • Yandex.Tank - единый отчет, масштабирование (Go, Python)

Нагрузочное тестирование:

  • Выдержит ли система планируемую нагрузку?
  • Есть ли узкие места?

При тестировании производительности можно определить 4 точки

  • точка работы, когда система работает оптимальным образом.
    • Обычно 80% от точки деградации
  • точка деградации, когда увеличивается время ответа системы
  • точка ошибок, когда в системе начали появляться ошибки, которых не было бы в точке работы
  • точка недоступности, когда система отказывается обрабатывать часть или все запросы


Тестирование стабильности. Тестирование системы в точке работы. Длительное тестирование со средней нагрузкой, преследует поиск отклонений и проверку корректности работы.

Отвечает на вопросы:

  • Что будет при эксплуатации 24/7?
  • Стабильная ли система под нагрузкой?
  • Как быстро растет размер базы данных и логов?
  • Есть ли утечка соединений, памяти?
  • Нет ли потерь данных?

Стрессовое тестирование. Тестирование за пределами рабочих нагрузок, в ограниченных ресурсах.

Отвечает на вопросы:

  • Если нагрузка ненадолго превысит максимум?
  • Освобождаются ли не используемые ресурсы?
  • Восстановится ли система после ошибок?
  • Какие ошибки появляются под нагрузкой?

Такое тестирование может позволить выявить утечки ресурсов.


Объемное тестирование. Тестирование при увеличенном объемов данных.

Отвечает на вопросы:

  • А что будет через 5-10 лет работы?
  • Что если размер документов увеличить?

Важно:

  • Увеличивается объем БД, а не интенсивность
  • Нужно иметь генератор нагрузки и данных
  • Быстрые генераторы БД пишутся на SQL

Тестирование масштабирования.

Отвечает на вопросы:

  • Поможет ли увеличение памяти в 2 раза?
  • Какой предел на другом железе?
  • Какая производительность при N серверах/репликах

Важно:

  • имеет физический предел