120 lines
6.3 KiB
Markdown
120 lines
6.3 KiB
Markdown
|
---
|
|||
|
|
parents:
|
|||
|
|
- "[[Архитектор высоких нагрузок - OTUS 2019]]"
|
|||
|
|
date: 2024-01-28
|
|||
|
|
zero-link:
|
|||
|
|
- "[[00 Архитектура ПО]]"
|
|||
|
|
---
|
|||
|
|
Интересные мысли
|
|||
|
|
- Отчеты по тестированию это чувствительные данные. Если отчеты попадут на в те руки, то они могут привести к подготовленной атаке на систему, что понесет за собой большие убытки. Поэтому отчеты по тестированию должны надежно храниться, и доступ к ним должен быть у ограниченного числа лиц.
|
|||
|
|
|
|||
|
|
На что чаще всего смотрят?
|
|||
|
|
- Быстрые ответы сервера
|
|||
|
|
- Эффективная утилизация ресурсов железа
|
|||
|
|
|
|||
|
|
Тестирование производительности
|
|||
|
|
- подсистемы серверов
|
|||
|
|
- Cмоделировать нагрузку на диск: [Flexible I/O Tester](https://github.com/axboe/fio) (fio).
|
|||
|
|
- Cмоделировать нагрузку на процессор: [Phoronix](https://phoronix-test-suite.com).
|
|||
|
|
- Cмоделировать нагрузку на сеть: [iperf3](iperf3.md).
|
|||
|
|
- серверов и приложений на простых запросах
|
|||
|
|
- подать нагрузку на балансировщик
|
|||
|
|
- подать нагрузку на БД
|
|||
|
|
- подать нагрузку на сервер приложений
|
|||
|
|
- приложение при выполнении сценариев
|
|||
|
|
- в соответствии с требованиями
|
|||
|
|
|
|||
|
|
**Статичные не связанные запросы к системе:**
|
|||
|
|
- Заданное количество повторений
|
|||
|
|
- Один или несколько фиксированных запросов
|
|||
|
|
- Точечная простая нагрузка
|
|||
|
|
|
|||
|
|
Утилиты для статичных запросов:
|
|||
|
|
- BASH-скриптом с curl/wget в цикле
|
|||
|
|
- На уровне TCP-протокола - tcpreplay
|
|||
|
|
- На MySQL - sysbench
|
|||
|
|
- На PostgreSQL - pgbench
|
|||
|
|
- На балансировщик - httperf (с паузами по списку URL)
|
|||
|
|
- На сервер - [Apache Benchmark](Apache%20Benchmark.md)
|
|||
|
|
|
|||
|
|
**Динамически связанные запросы к системе**
|
|||
|
|
- Высокая интенсивность, но неконтролируемая
|
|||
|
|
- Запросы, связанными в сценарий
|
|||
|
|
|
|||
|
|
**Точная нагрузка по требованиям**
|
|||
|
|
- В подходящее время и в нужном месте
|
|||
|
|
- С нужно нагрузкой
|
|||
|
|
- С анализом происходящего
|
|||
|
|
|
|||
|
|
Утилиты для точной нагрузки:
|
|||
|
|
- [Jmeter](Jmeter.md) - простые сценарии (Groovy, Java, JavaScript)
|
|||
|
|
- Gatling - сложные сценарии с десятками запросов (Scala)
|
|||
|
|
- wrk - автоматизация на Lua
|
|||
|
|
- Yandex.Tank - единый отчет, масштабирование (Go, Python)
|
|||
|
|
|
|||
|
|
***
|
|||
|
|
**Нагрузочное тестирование:**
|
|||
|
|
- Выдержит ли система планируемую нагрузку?
|
|||
|
|
- Есть ли узкие места?
|
|||
|
|
|
|||
|
|
При тестировании производительности можно определить 4 точки
|
|||
|
|
- **точка работы**, когда система работает оптимальным образом.
|
|||
|
|
- Обычно 80% от точки деградации
|
|||
|
|
- **точка деградации**, когда увеличивается время ответа системы
|
|||
|
|
- **точка ошибок**, когда в системе начали появляться ошибки, которых не было бы в точке работы
|
|||
|
|
- **точка недоступности**, когда система отказывается обрабатывать часть или все запросы
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
***
|
|||
|
|
|
|||
|
|
**Тестирование стабильности.** Тестирование системы в точке работы. Длительное тестирование со средней нагрузкой, преследует поиск отклонений и проверку корректности работы.
|
|||
|
|
|
|||
|
|
Отвечает на вопросы:
|
|||
|
|
- Что будет при эксплуатации 24/7?
|
|||
|
|
- Стабильная ли система под нагрузкой?
|
|||
|
|
- Как быстро растет размер базы данных и логов?
|
|||
|
|
- Есть ли утечка соединений, памяти?
|
|||
|
|
- Нет ли потерь данных?
|
|||
|
|
|
|||
|
|
***
|
|||
|
|
**Стрессовое тестирование.** Тестирование за пределами рабочих нагрузок, в ограниченных ресурсах.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Отвечает на вопросы:
|
|||
|
|
- Если нагрузка ненадолго превысит максимум?
|
|||
|
|
- Освобождаются ли не используемые ресурсы?
|
|||
|
|
- Восстановится ли система после ошибок?
|
|||
|
|
- Какие ошибки появляются под нагрузкой?
|
|||
|
|
|
|||
|
|
Такое тестирование может позволить выявить утечки ресурсов.
|
|||
|
|
|
|||
|
|
|
|||
|
|
***
|
|||
|
|
|
|||
|
|
**Объемное тестирование.** Тестирование при увеличенном объемов данных.
|
|||
|
|
|
|||
|
|
Отвечает на вопросы:
|
|||
|
|
- А что будет через 5-10 лет работы?
|
|||
|
|
- Что если размер документов увеличить?
|
|||
|
|
|
|||
|
|
Важно:
|
|||
|
|
- Увеличивается объем БД, а не интенсивность
|
|||
|
|
- Нужно иметь генератор нагрузки и данных
|
|||
|
|
- Быстрые генераторы БД пишутся на SQL
|
|||
|
|
|
|||
|
|
***
|
|||
|
|
|
|||
|
|
**Тестирование масштабирования.**
|
|||
|
|
|
|||
|
|
Отвечает на вопросы:
|
|||
|
|
- Поможет ли увеличение памяти в 2 раза?
|
|||
|
|
- Какой предел на другом железе?
|
|||
|
|
- Какая производительность при N серверах/репликах
|
|||
|
|
|
|||
|
|
Важно:
|
|||
|
|
- имеет физический предел
|
|||
|
|
|
|||
|
|
***
|