5. Цели
1 Не допустить performance-деградаций
2 Если допустили, то вовремя об этом узнать
3/30 1. Общая методология
6. Цели
1 Не допустить performance-деградаций
2 Если допустили, то вовремя об этом узнать
3 Снизить количество ошибок первого рода
(Проблемы нет, а мы думаем, что есть)
3/30 1. Общая методология
7. Цели
1 Не допустить performance-деградаций
2 Если допустили, то вовремя об этом узнать
3 Снизить количество ошибок первого рода
(Проблемы нет, а мы думаем, что есть)
4 Снизить количество ошибок второго рода
(Проблема есть, а мы думаем, что нет)
3/30 1. Общая методология
8. Цели
1 Не допустить performance-деградаций
2 Если допустили, то вовремя об этом узнать
3 Снизить количество ошибок первого рода
(Проблемы нет, а мы думаем, что есть)
4 Снизить количество ошибок второго рода
(Проблема есть, а мы думаем, что нет)
5 Автоматизация везде, где можно
3/30 1. Общая методология
10. Источник для вдохновения
Rider
• Файлов: 200’000+
• Строчек кода: 20’000’000+
• Тестов: 100’000+
• Рантаймы внутри: JVM, .NET Framework/Mono
• Быстро работает на Windows, Linux, macOS
5/30 1. Общая методология
11. Источник для вдохновения
Rider
• Файлов: 200’000+
• Строчек кода: 20’000’000+
• Тестов: 100’000+
• Рантаймы внутри: JVM, .NET Framework/Mono
• Быстро работает на Windows, Linux, macOS
Хочется, чтобы Rider продолжал быстро работать...
5/30 1. Общая методология
16. Источники performance-данных: крупно
Специальные performance-тесты
• Холодный и горячий старт
• Микробенчмарки
• Performance-тесты на GUI
• Нагрузочное тестирование (Яндекс.Танк, JMeter и т.д.)
6/30 1. Общая методология
17. Источники performance-данных: крупно
Специальные performance-тесты
• Холодный и горячий старт
• Микробенчмарки
• Performance-тесты на GUI
• Нагрузочное тестирование (Яндекс.Танк, JMeter и т.д.)
• Измерение Latency/Throughput
6/30 1. Общая методология
18. Источники performance-данных: крупно
Специальные performance-тесты
• Холодный и горячий старт
• Микробенчмарки
• Performance-тесты на GUI
• Нагрузочное тестирование (Яндекс.Танк, JMeter и т.д.)
• Измерение Latency/Throughput
• Автоматизированный поиск точек отказа (capacity planning)
6/30 1. Общая методология
19. Источники performance-данных: крупно
Специальные performance-тесты
• Холодный и горячий старт
• Микробенчмарки
• Performance-тесты на GUI
• Нагрузочное тестирование (Яндекс.Танк, JMeter и т.д.)
• Измерение Latency/Throughput
• Автоматизированный поиск точек отказа (capacity planning)
• Тестирование асимптотики
6/30 1. Общая методология
20. Источники performance-данных: крупно
Специальные performance-тесты
• Холодный и горячий старт
• Микробенчмарки
• Performance-тесты на GUI
• Нагрузочное тестирование (Яндекс.Танк, JMeter и т.д.)
• Измерение Latency/Throughput
• Автоматизированный поиск точек отказа (capacity planning)
• Тестирование асимптотики
• ...
6/30 1. Общая методология
21. Источники performance-данных: крупно
Специальные performance-тесты
• Холодный и горячий старт
• Микробенчмарки
• Performance-тесты на GUI
• Нагрузочное тестирование (Яндекс.Танк, JMeter и т.д.)
• Измерение Latency/Throughput
• Автоматизированный поиск точек отказа (capacity planning)
• Тестирование асимптотики
• ...
Обычные тесты
• Все тесты, которые у вас уже есть (>10ms)
6/30 1. Общая методология
22. Обычные тесты vs. Специальные тесты
Обычные тесты Специальные тесты
7/30 1. Общая методология
23. Обычные тесты vs. Специальные тесты
Обычные тесты Специальные тесты
Случайные машины Выделенные машины
7/30 1. Общая методология
24. Обычные тесты vs. Специальные тесты
Обычные тесты Специальные тесты
Случайные машины Выделенные машины
Виртуальное окружение Реальное железо
7/30 1. Общая методология
25. Обычные тесты vs. Специальные тесты
Обычные тесты Специальные тесты
Случайные машины Выделенные машины
Виртуальное окружение Реальное железо
Легко писать Сложно писать
7/30 1. Общая методология
26. Обычные тесты vs. Специальные тесты
Обычные тесты Специальные тесты
Случайные машины Выделенные машины
Виртуальное окружение Реальное железо
Легко писать Сложно писать
Много и бесплатно Мало и дорого
7/30 1. Общая методология
28. Поучительная история
Однажды, после перехода с Mono 4.9 на Mono 5.2 наши
perf-тесты стали падать . . .
private readonly IList<object> array = new string[0];
[Benchmark]
public int CountProblem() => array.Count;
8/30 1. Общая методология
29. Поучительная история
Однажды, после перехода с Mono 4.9 на Mono 5.2 наши
perf-тесты стали падать . . .
private readonly IList<object> array = new string[0];
[Benchmark]
public int CountProblem() => array.Count;
Linux macOS
Mono 4.9 ≈5ns ≈5ns
Mono 5.2 ≈1400ns ≈2600ns
8/30 1. Общая методология
31. Источники performance-данных: мелко
Ветки
• Master-ветка
• Все ветки
• Заданные коммиты
Метрики
• Время прохождения теста
• Время прохождения отдельных частей теста
• "Железные"данные: CPU, Memory, Disk, Network, . . .
• Характеристики рантайма (например, GC.CollectionCount)
9/30 1. Общая методология
32. Источники performance-данных: мелко
Ветки
• Master-ветка
• Все ветки
• Заданные коммиты
Метрики
• Время прохождения теста
• Время прохождения отдельных частей теста
• "Железные"данные: CPU, Memory, Disk, Network, . . .
• Характеристики рантайма (например, GC.CollectionCount)
Не забываем про проблему множественных сравнений
9/30 1. Общая методология
35. Оборона против performance-деградаций
• Merge robot
Проверяем производительность на каждый мердж
• Daily tests
Запускаем тесты каждый день
10/30 1. Общая методология
36. Оборона против performance-деградаций
• Merge robot
Проверяем производительность на каждый мердж
• Daily tests
Запускаем тесты каждый день
• Retrospective
Анализируем исторические данные
10/30 1. Общая методология
37. Оборона против performance-деградаций
• Merge robot
Проверяем производительность на каждый мердж
• Daily tests
Запускаем тесты каждый день
• Retrospective
Анализируем исторические данные
• Check points
Проверяем опасные изменения
10/30 1. Общая методология
38. Оборона против performance-деградаций
• Merge robot
Проверяем производительность на каждый мердж
• Daily tests
Запускаем тесты каждый день
• Retrospective
Анализируем исторические данные
• Check points
Проверяем опасные изменения
• Pre-release
Проверяем регрессию перед самым релизом
10/30 1. Общая методология
42. Оборона против performance-деградаций
Обнаружение Точность Процесс
Merge robot Вовремя Средняя Автоматический
Daily tests Поздно Хорошая Полуручной
Retrospective Слишком поздно Отличная Полуручной
11/30 1. Общая методология
43. Оборона против performance-деградаций
Обнаружение Точность Процесс
Merge robot Вовремя Средняя Автоматический
Daily tests Поздно Хорошая Полуручной
Retrospective Слишком поздно Отличная Полуручной
Check points Вовремя Отличная Ручной
11/30 1. Общая методология
44. Оборона против performance-деградаций
Обнаружение Точность Процесс
Merge robot Вовремя Средняя Автоматический
Daily tests Поздно Хорошая Полуручной
Retrospective Слишком поздно Отличная Полуручной
Check points Вовремя Отличная Ручной
Pre-release Совсем поздно Отличная Ручной
11/30 1. Общая методология
45. Оборона против performance-деградаций
Обнаружение Точность Процесс
Merge robot Вовремя Средняя Автоматический
Daily tests Поздно Хорошая Полуручной
Retrospective Слишком поздно Отличная Полуручной
Check points Вовремя Отличная Ручной
Pre-release Совсем поздно Отличная Ручной
И ещё несколько важных факторов:
• Время прогона
• Количество билд-агентов и их стоимость
• Спектр проблем, которые можно обнаружить
11/30 1. Общая методология
51. Alarm-критерии
Ручной
• Специальный программист, который мониторит тесты 24/7
Автоматизированный
• Абсолютный timeout
• Относительный timeout
• Исторические данные и статистика
12/30 1. Общая методология
52. Alarm-критерии
Ручной
• Специальный программист, который мониторит тесты 24/7
Автоматизированный
• Абсолютный timeout
• Относительный timeout
• Исторические данные и статистика
Полуавтоматизированный
• Система, которая формирует список performance-аномалий
• Специальный программист, который разбирает этот список
12/30 1. Общая методология
56. Виды performance-аномалий
• Деградация производительности (резкая и постепенная)
• Деградация индивидуальная и групповая
14/30 2. Ищем performance-аномалии
57. Виды performance-аномалий
• Деградация производительности (резкая и постепенная)
• Деградация индивидуальная и групповая
• Внезапное улучшение производительности
14/30 2. Ищем performance-аномалии
58. Виды performance-аномалий
• Деградация производительности (резкая и постепенная)
• Деградация индивидуальная и групповая
• Внезапное улучшение производительности
• Разная производительность в зависимости от параметров и окружения
14/30 2. Ищем performance-аномалии
59. Виды performance-аномалий
• Деградация производительности (резкая и постепенная)
• Деградация индивидуальная и групповая
• Внезапное улучшение производительности
• Разная производительность в зависимости от параметров и окружения
• Большая дисперсия
14/30 2. Ищем performance-аномалии
60. Виды performance-аномалий
• Деградация производительности (резкая и постепенная)
• Деградация индивидуальная и групповая
• Внезапное улучшение производительности
• Разная производительность в зависимости от параметров и окружения
• Большая дисперсия
• Распределения странной формы (например, мультимодальные)
14/30 2. Ищем performance-аномалии
61. Виды performance-аномалий
• Деградация производительности (резкая и постепенная)
• Деградация индивидуальная и групповая
• Внезапное улучшение производительности
• Разная производительность в зависимости от параметров и окружения
• Большая дисперсия
• Распределения странной формы (например, мультимодальные)
• . . .
14/30 2. Ищем performance-аномалии
64. Борьба с performance-аномалиями
Наведение performance-чистоты позволяет:
• Находить проблемы, на которые не стоят assert’ы
• Ускорять билд
15/30 2. Ищем performance-аномалии
65. Борьба с performance-аномалиями
Наведение performance-чистоты позволяет:
• Находить проблемы, на которые не стоят assert’ы
• Ускорять билд
• Находить flaky-тесты
15/30 2. Ищем performance-аномалии
66. Борьба с performance-аномалиями
Наведение performance-чистоты позволяет:
• Находить проблемы, на которые не стоят assert’ы
• Ускорять билд
• Находить flaky-тесты
• Уменьшать количество тестов, которые в будущем помешают найти
действительно критичные проблемы
15/30 2. Ищем performance-аномалии
79. Ложные друзья performance-инженера
• Изменения в тесте
• Изменения в порядке тестов
• Изменения в агенте
• Изменения в окружающем мире
24/30 2. Ищем performance-аномалии
80. Ложные друзья performance-инженера
• Изменения в тесте
• Изменения в порядке тестов
• Изменения в агенте
• Изменения в окружающем мире
• Любые изменения хоть в чём, кроме того, что вы
действительно тестируете
24/30 2. Ищем performance-аномалии
82. Performance Culture
Внутри команды должно быть единое понимание следующих
вещей:
• Performance-цели
• Идеальная степень performance-чистоты
• Кто за что ответственен
• Что считать регрессией или проблемой
• Что такое правильный tradeoff
26/30 3. Performance Culture
90. Мораль
• Performance-тестирование — увлекательно, но сложно
• Набор проблем и решений специфичен для продукта.
Хорошие инструменты не помогут вам, если вы не понимаете
мат.части.
• Куча данных бесплатно валяется под ногами.
Нужно просто уметь их собрать!
29/30 4. Заключительные мысли