---
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% от точки деградации
- **точка деградации**, когда увеличивается время ответа системы
- **точка ошибок**, когда в системе начали появляться ошибки, которых не было бы в точке работы
- **точка недоступности**, когда система отказывается обрабатывать часть или все запросы

![](Pasted%20image%2020240128202510.png)

***

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

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

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

![](Pasted%20image%2020240128204046.png)

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

Такое тестирование может позволить выявить утечки ресурсов.
![](Pasted%20image%2020240128204149.png)

***

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

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

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

***

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

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

Важно:
- имеет физический предел

***