6.3 KiB
parents | date | zero-link | ||
---|---|---|---|---|
|
2024-01-28 |
|
Интересные мысли
- Отчеты по тестированию это чувствительные данные. Если отчеты попадут на в те руки, то они могут привести к подготовленной атаке на систему, что понесет за собой большие убытки. Поэтому отчеты по тестированию должны надежно храниться, и доступ к ним должен быть у ограниченного числа лиц.
На что чаще всего смотрят?
- Быстрые ответы сервера
- Эффективная утилизация ресурсов железа
Тестирование производительности
- подсистемы серверов
- Cмоделировать нагрузку на диск: Flexible I/O Tester (fio).
- Cмоделировать нагрузку на процессор: Phoronix.
- Cмоделировать нагрузку на сеть: 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 серверах/репликах
Важно:
- имеет физический предел