# Мысли по нагрузочному тестированию Karbor
## Цель нагрузочного тестирования
- Проверить что средний абстрактный профиль нагрузки не уронит нам инфраструктуру
- Установление пределов в которых карбор будет работать без падений
- Получение профиля нагрузки, которую карбор дает на инфраструктуру

## Определяемся со степенями свободы
Изначально планировалось изменять следующие параметры:

| Параметр | Значения |
| ------------------------------ | ---------------------- |
| Количество планов на проект | 20, 40, 60, 80, 100 |
| Количество дисков в одном плане | 20, 40, 60, 80, 100 |
| Размер дисков | 10, 35, 60, 1000, 4000 |
| Наполненность диска | 0, 20, 40, 60, 80 |
| Количество операций на триггер | 2, 4, 6, 8, 10 |
| Количество триггеров на проект | 4, 16, 24, 32, 40 |
| Количество проектов | 1, 5, 10 |

С такими значениями параметров получается слишком много кейсов.
Оптимизация по параметрам:
* Количество планов на проект
Здесь проверяется способность карбора обрабатывать много дисков.
Тут можно исходить из данных о количестве дисков на проект.
В ru-3 3 диска на проект это 63 перцентиль, 20 дисков на проект это 95 перцентиль и 100 дисков на проект это 99 перцентиль.
Можно оставить 3 этих значения.
Решение: оставляем значения 3, 20, 100

* Количество дисков в одном плане
Планировалось проверить как будет производиться создание бэкапов с несколькими дисками.
Если подумать, то ничего нового по профилю нагрузки это не даст по сравнению с количеством планов на проект.
Поэтому этот параметр убираем из тестирования вообще.

* Размер дисков
От этого параметра зависит длительность создания бэкапа и восстановления из него.
Размер дисков напрямую нагружает ceph. Еще нужно учитывать, что на waxwing не бесконечное место, поэтому нужно будет убрать случаи когда
мы не помещаемся в ceph по размеру.
Размеры дисков выбраны исходя из данных по ru-3.
25% - 10 Гб
73% - 35 Гб
83% - 60 Гб
99.63% - 1000 Гб
Решение: оставляем значения 10, 35, 60, 1000

* Наполненность диска
Эта характеристика будет влиять на длительность создания бэкапов.
Дополнительно, чем больше заполненность тем больше будет гоняться по сети в rbd.
Достаточно оставить среднее и максимальное значение. Например, 20 и 60.
Вообще можно зафиксировать на 60, так как 20 скорее всего ничего в плане нагрузки не даст.
С другой стороны хотелось бы посмотреть разницу между долгим созданием нескольких бэкапов и быстрым созданием большого количества мелких.
Подобную проверку можно сделать зафиксировав наполненость диска на 60 и меняя только размер диска.
Решение: фиксируем на 60.

* Количество операций на триггер
Этим параметром хотелось проверить как каждый отдельный operationengine будет справляться с триггером, у которого несколько операций.
Сейчас параметр max_concurrent_operations у нас равен 0, это значит, что нет ограничения на количество создаваемых гринлетов.
В проде у нас может быть ситуация, когда у триггера будет много запланированных операций, поэтому этот параметр выбрасывать бы не хотелось.
Так как есть взаимосвязь между количеством планов, триггерами на проект и операциями на триггер, то можно этот параметр убрать.
Перебором количества планов и количества триггеров мы получим разное количество операций на триггер.
Решение: исключаем из тестов

* Количество триггеров на проект
Тут мы проверяем механизм обработки триггеров несколькими operationengine.
На данный момент развернуто 4 ноды operationengine, поэтому было бы удобно если количество триггеров делилось на 4.
Так мы сможем посмотреть нормально ли балансируется нагрузка между operationengine.
Решение: оставляем значения 4, 16, 24, 32, 40

* Количество проектов
Этот параметр нужен для проверки корректности работы карбора с трастами.
Зафиксируем количество проектов равным 3 на протяжении всего тестирования.
Решение: фиксируем на 3.

Итого:
| Параметр | Значения |
| ------------------------------ | ---------------------- |
| Количество планов на проект | 3, 20, 100 |
| Количество дисков в одном плане | Выбрасываем |
| Размер дисков | 10, 35, 60, 1000 |
| Наполненность диска | 60 |
| Количество операций на триггер | Выбрасываем |
| Количество триггеров на проект | 4, 16, 24, 32, 40 |
| Количество проектов | 3 |

> NOTE: Есть взаимосвязь между количеством планов на проект, триггерами на проект и операциями на триггер.

## Общие моменты
- Длительность одного сценария составит 4 часа.
- В один из сценариев дополнительно введем тесты на восстановление дисков из бэкапов.
- Если во время одного из сценариев карбор перестанет работать, то нужно будет собрать как можно больше информации о том почему так произошло.
- Во время тестов будем считать 1 план = 1 диск
- У запланированных операций фиксируем max_backups = 1
- Так как нам важно получать пиковые нагрузки, то во всех тестах триггеры будут срабатывать в одно и то же время.

## Подходы к проведению тестирования
> В результатах не убраны неподходящие кейсы!
### Использование pairwise с отбрасыванием неподходящих случаев

Входные параметры:

plan_per_project:  3, 20, 100
disk_size: 10, 35, 60, 1000
disk_fill_percent: 60  
trigger_per_project:  4, 16, 24, 32, 40
projects:  3

Результат:

| plan_per_project | disk_size | disk_fill_percent | trigger_per_project | projects |
|------------------|-----------|-------------------|---------------------|----------|
| 3 | 60 | 60 | 16 | 3 |
| 100 | 35 | 60 | 24 | 3 |
| 20 | 35 | 60 | 40 | 3 |
| 100 | 10 | 60 | 40 | 3 |
| 100 | 1000 | 60 | 4 | 3 |
| 20 | 60 | 60 | 24 | 3 |
| 20 | 1000 | 60 | 16 | 3 |
| 3 | 60 | 60 | 4 | 3 |
| 20 | 10 | 60 | 32 | 3 |
| 3 | 60 | 60 | 40 | 3 |
| 3 | 1000 | 60 | 40 | 3 |
| 3 | 1000 | 60 | 24 | 3 |
| 100 | 35 | 60 | 16 | 3 |
| 20 | 35 | 60 | 4 | 3 |
| 100 | 60 | 60 | 32 | 3 |
| 3 | 1000 | 60 | 32 | 3 |
| 3 | 10 | 60 | 24 | 3 |
| 100 | 10 | 60 | 4 | 3 |
| 100 | 10 | 60 | 16 | 3 |
| 3 | 35 | 60 | 32 | 3 |

Получается слишком много тест кейсов.
Если убрать промежуточные значения то получится чуть меньше.
Входные параметры:

plan_per_project:  3, 20, 100
disk_size: 35, 1000
disk_fill_percent: 60  
trigger_per_project:  4, 24, 40
projects:  3

Результат:

| plan_per_project | disk_size | disk_fill_percent | trigger_per_project | projects |
|------------------|-----------|-------------------|---------------------|----------|
| 3 | 35 | 60 | 4 | 3 |
| 3 | 1000 | 60 | 24 | 3 |
| 20 | 35 | 60 | 24 | 3 |
| 100 | 35 | 60 | 24 | 3 |
| 100 | 1000 | 60 | 40 | 3 |
| 20 | 1000 | 60 | 4 | 3 |
| 100 | 1000 | 60 | 4 | 3 |
| 20 | 35 | 60 | 40 | 3 |
| 3 | 35 | 60 | 40 | 3 |

#### Плюсы
- Так получится снять наиболее полные профили по нагрузке

#### Минусы
- Могут возникнуть проблемы с интерпретацией результатов

### Плавный проход по параметрам
Тут идея в том, чтобы начать со среднего случая. Продолжить кейсами с увеличением каждого из параметров. И закончить на максимумах.
Предлагаются следующие тест кейсы:

| plan_per_project | disk_size | disk_fill_percent | trigger_per_project | projects | description |
|------------------|-----------|-------------------|---------------------|----------|-------------------------|
| 20 | 35 | 60 | 24 | 3 | средний случай |
| 100 | 35 | 60 | 4 | 3 | max plan_per_project |
| 3 | 1000 | 60 | 4 | 3 | max disk_size |
| 3 | 35 | 60 | 40 | 3 | max trigger_per_project |
| 100 | 1000 | 60 | 40 | 3 | all max |

#### Плюсы
- Мало тест кейсов
- Понятнее что происходит в каждом кейсе => меньше проблем с интерпретацией

#### Минусы
- Кроме первого и последнего теста не отражает реальный профиль нагрузки. Остальные тесты дают профиль нагрузки по конкретному параметру.
- Непонятно как увеличивается нагрузка в зависимости от увеличения параметра (два мало).

### Увеличение всех параметров на каждой итерации
Тут основная идея найти параметры при которых все свалится.
Предлагается два варианта сценариев.

#### Вариант 1

| plan_per_project | disk_size | disk_fill_percent | trigger_per_project | projects | op_per_trigger | total_disk_size |
|------------------|-----------|-------------------|---------------------|----------|----------------|-----------------|
| 12 | 100 | 60 | 12 | 3 | 1 | 1200 Gb |
| 20 | 140 | 60 | 20 | 3 | 1 | 2800 Gb |
| 60 | 70 | 60 | 30 | 3 | 2 | 4200 Gb |
| 80 | 70 | 60 | 40 | 3 | 2 | 5600 Gb |
| 150 | 45 | 60 | 50 | 3 | 3 | 6750 Gb |

Немного подкорректировал первый вариант, чтобы росло количество запланированных операций на триггер.
И изменил размеры дисков чтобы нагрузка также возрастала от сценария к сценарию.

#### Вариант 2
Здесь размер диска изменяется от большего к меньшему. При таком подходе тест кейсы влезут в ceph.

| plan_per_project | disk_size | disk_fill_percent | trigger_per_project | projects |
|------------------|-----------|-------------------|---------------------|----------|
| 3 | 100 | 60 | 1 | 3 |
| 20 | 70 | 60 | 4 | 3 |
| 40 | 50 | 60 | 24 | 3 |
| 60 | 35 | 60 | 40 | 3 |
| 100 | 10 | 60 | 100 | 3 |

#### Плюсы
- Такой подход позволит быстро определить пределы возможностей нашей инфраструктуры

#### Минусы
- Есть ощущение, что профили нагрузки будет сложно анализировать

### Решение
После обсуждения стратегии тестирования договорились тестировать по следующему сценарию:

| plan_per_project | disk_size | disk_fill_percent | trigger_per_project | projects | op_per_trigger | total_disk_size |
|------------------|-----------|-------------------|---------------------|----------|----------------|-----------------|
| 12 | 100 | 60 | 12 | 3 | 1 | 1200 Gb |
| 20 | 140 | 60 | 20 | 3 | 1 | 2800 Gb |
| 60 | 70 | 60 | 30 | 3 | 2 | 4200 Gb |
| 80 | 70 | 60 | 40 | 3 | 2 | 5600 Gb |
| 150 | 45 | 60 | 50 | 3 | 3 | 6750 Gb |

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