---
# System prepended metadata

title: Мысли по нагрузочному тестированию Karbor

---

# Мысли по нагрузочному тестированию 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    |

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