Сложности performance-тестирования / Андрей Акиньшин (JetBrains)
0 likes357 views
Документ описывает общую методологию для предотвращения деградации производительности, включая автоматизацию, проведение различных тестов и анализ исторических данных. Основное внимание уделяется обнаружению производственных аномалий и их борьбе, а также важности регулярного мониторинга и тестирования. Метрики и способы измерения производительности подчеркиваются как важные аспекты для поддержания стабильной работы систем.
![Поучительная история
Однажды, после перехода с Mono 4.9 на Mono 5.2 наши
perf-тесты стали падать . . .
private readonly IList<object> array = new string[0];
[Benchmark]
public int CountProblem() => array.Count;
8/30 1. Общая методология](https://image.slidesharecdn.com/2-171110184944/85/performance-JetBrains-28-320.jpg)
![Поучительная история
Однажды, после перехода с 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. Общая методология](https://image.slidesharecdn.com/2-171110184944/85/performance-JetBrains-29-320.jpg)
Сложности performance-тестирования / Андрей Акиньшин (JetBrains)
- 2. Часть 1 Общая методология 2/30 1. Общая методология
- 3. Цели 3/30 1. Общая методология
- 4. Цели 1 Не допустить performance-деградаций 3/30 1. Общая методология
- 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. Общая методология
- 9. Источник для вдохновения 4/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. Общая методология
- 12. Источники performance-данных: крупно Специальные performance-тесты 6/30 1. Общая методология
- 13. Источники performance-данных: крупно Специальные performance-тесты • Холодный и горячий старт 6/30 1. Общая методология
- 14. Источники performance-данных: крупно Специальные performance-тесты • Холодный и горячий старт • Микробенчмарки 6/30 1. Общая методология
- 15. Источники performance-данных: крупно Специальные performance-тесты • Холодный и горячий старт • Микробенчмарки • Performance-тесты на GUI 6/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. Общая методология
- 27. Поучительная история Однажды, после перехода с Mono 4.9 на Mono 5.2 наши perf-тесты стали падать . . . 8/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. Общая методология
- 30. Источники performance-данных: мелко Ветки • Master-ветка • Все ветки • Заданные коммиты 9/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. Общая методология
- 33. Оборона против performance-деградаций 10/30 1. Общая методология
- 34. Оборона против performance-деградаций • Merge robot Проверяем производительность на каждый мердж 10/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. Общая методология
- 39. Оборона против performance-деградаций Обнаружение Точность Процесс 11/30 1. Общая методология
- 40. Оборона против performance-деградаций Обнаружение Точность Процесс Merge robot Вовремя Средняя Автоматический 11/30 1. Общая методология
- 41. Оборона против performance-деградаций Обнаружение Точность Процесс Merge robot Вовремя Средняя Автоматический Daily tests Поздно Хорошая Полуручной 11/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. Общая методология
- 46. Alarm-критерии 12/30 1. Общая методология
- 47. Alarm-критерии Ручной • Специальный программист, который мониторит тесты 24/7 12/30 1. Общая методология
- 48. Alarm-критерии Ручной • Специальный программист, который мониторит тесты 24/7 Автоматизированный 12/30 1. Общая методология
- 49. Alarm-критерии Ручной • Специальный программист, который мониторит тесты 24/7 Автоматизированный • Абсолютный timeout 12/30 1. Общая методология
- 50. Alarm-критерии Ручной • Специальный программист, который мониторит тесты 24/7 Автоматизированный • Абсолютный timeout • Относительный timeout 12/30 1. Общая методология
- 51. Alarm-критерии Ручной • Специальный программист, который мониторит тесты 24/7 Автоматизированный • Абсолютный timeout • Относительный timeout • Исторические данные и статистика 12/30 1. Общая методология
- 52. Alarm-критерии Ручной • Специальный программист, который мониторит тесты 24/7 Автоматизированный • Абсолютный timeout • Относительный timeout • Исторические данные и статистика Полуавтоматизированный • Система, которая формирует список performance-аномалий • Специальный программист, который разбирает этот список 12/30 1. Общая методология
- 53. Часть 2 Ищем performance-аномалии 13/30 2. Ищем performance-аномалии
- 54. Виды performance-аномалий 14/30 2. Ищем performance-аномалии
- 55. Виды performance-аномалий • Деградация производительности (резкая и постепенная) 14/30 2. Ищем performance-аномалии
- 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-аномалии
- 62. Борьба с performance-аномалиями Наведение performance-чистоты позволяет: 15/30 2. Ищем performance-аномалии
- 63. Борьба с performance-аномалиями Наведение performance-чистоты позволяет: • Находить проблемы, на которые не стоят assert’ы 15/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-аномалии
- 67. Маленькие деградации 16/30 2. Ищем performance-аномалии
- 68. Дисперсия 17/30 2. Ищем performance-аномалии
- 69. Анализ параметров 18/30 2. Ищем performance-аномалии
- 70. Анализ параметров 19/30 2. Ищем performance-аномалии
- 71. Анализ параметров 20/30 2. Ищем performance-аномалии
- 72. Мультимодальные распределения 21/30 2. Ищем performance-аномалии
- 73. Мультимодальные распределения 22/30 2. Ищем performance-аномалии
- 74. Проблемы агентов 23/30 2. Ищем performance-аномалии
- 75. Ложные друзья performance-инженера 24/30 2. Ищем performance-аномалии
- 76. Ложные друзья performance-инженера • Изменения в тесте 24/30 2. Ищем performance-аномалии
- 77. Ложные друзья performance-инженера • Изменения в тесте • Изменения в порядке тестов 24/30 2. Ищем performance-аномалии
- 78. Ложные друзья performance-инженера • Изменения в тесте • Изменения в порядке тестов • Изменения в агенте 24/30 2. Ищем performance-аномалии
- 79. Ложные друзья performance-инженера • Изменения в тесте • Изменения в порядке тестов • Изменения в агенте • Изменения в окружающем мире 24/30 2. Ищем performance-аномалии
- 80. Ложные друзья performance-инженера • Изменения в тесте • Изменения в порядке тестов • Изменения в агенте • Изменения в окружающем мире • Любые изменения хоть в чём, кроме того, что вы действительно тестируете 24/30 2. Ищем performance-аномалии
- 81. Часть 3 Performance Culture 25/30 3. Performance Culture
- 82. Performance Culture Внутри команды должно быть единое понимание следующих вещей: • Performance-цели • Идеальная степень performance-чистоты • Кто за что ответственен • Что считать регрессией или проблемой • Что такое правильный tradeoff 26/30 3. Performance Culture
- 83. Performance Driven Development (PDD) 27/30 3. Performance Culture
- 84. Performance Driven Development (PDD) • Пишем performance-тест 27/30 3. Performance Culture
- 85. Performance Driven Development (PDD) • Пишем performance-тест • Изучаем performance-пространство: Min, Max, Mean, Median, Q1, Q3, Percentiles, графики и тренды 27/30 3. Performance Culture
- 86. Performance Driven Development (PDD) • Пишем performance-тест • Изучаем performance-пространство: Min, Max, Mean, Median, Q1, Q3, Percentiles, графики и тренды • Задаём reference state 27/30 3. Performance Culture
- 87. Performance Driven Development (PDD) • Пишем performance-тест • Изучаем performance-пространство: Min, Max, Mean, Median, Q1, Q3, Percentiles, графики и тренды • Задаём reference state • Делаем рефакторинг и оптимизации 27/30 3. Performance Culture
- 88. Performance Driven Development (PDD) • Пишем performance-тест • Изучаем performance-пространство: Min, Max, Mean, Median, Q1, Q3, Percentiles, графики и тренды • Задаём reference state • Делаем рефакторинг и оптимизации • Проверяем performance-показатели 27/30 3. Performance Culture
- 89. Часть 4 Заключительные мысли 28/30 4. Заключительные мысли
- 90. Мораль • Performance-тестирование — увлекательно, но сложно • Набор проблем и решений специфичен для продукта. Хорошие инструменты не помогут вам, если вы не понимаете мат.части. • Куча данных бесплатно валяется под ногами. Нужно просто уметь их собрать! 29/30 4. Заключительные мысли