Комментарии 7
А потом наше распределение внезапно становится бимодальным. И тут уже сложно сказать деградация ли это или ускорение, но что-то важное определённо поменялось. А потом распределение и вовсе становится тримодальным.
Картинка напомнила бифуркационную диаграмму обычно появляющуюся при анализе динамических нелинейных систем. Интересно, при увеличении числа операции система точно-также демонстрирует хаотическое поведение?

Картинки
Картинка из статьи
image
Типичная бифуркационная диаграмма
image

В тексте часто встречается опечатка «рейс» в значении «кейс»

А может должно было быть именно "рейс" в смысле "race condition"? Я именно так прочитал. Ну и по контексту подходило.


PS: залез в видео. Как минимум на 58:06 слышу именно "рейс", на 23:43 тоже. Так что верните обратно. Те, кто достаточно занимается производительностью поняли Андрея правильно :)

Перешла по тайм-кодам, переслушала — действительно, поторопилась с исправлениями. Спасибо вам за внимательность
Спасибо за доклад из расшифровку доклада!
Насколько я понял из статьи, в JB непрерывно тестируют производительность. Но в то же время за один запуск нельзя понять приносит ли патч деградацию или нет, потому что для анализа нужны метрики за какой-то период времени. Вопрос к DreamWalker: как вы управляете коммитами, которые принесли регрессию: откат изменений (иногда это сложно, потому что сверху уже есть другие изменения), оперативный фикс регрессии или что-то ещё?

В целом мы пытаемся добиться ситуации, в которой значимые деградации просто не могут вмёрджиться. Для этого у нас есть performance-тесты, которые динамически подбирают оптимальное количество итераций (в докладе я как раз про это рассказываю). Для пущей уверенности тесты перезапускаются на нескольких машинах, чтобы гарантированно избежать ложноположительных результатов.
Но вы правы в том, что такие тесты не всегда спасают от регрессий. Пожалуй, самая главная проблема в том, что таких тестов не очень много (т.к. они очень долго идут), покрыты только наиболее критичные сценарии. Поэтому есть система мониторинга, которая шлёт в Slack разнообразные нотификации об уже замёрдженных деградациях. Какого-то красивого универсального подхода к таким проблемам нет, мы просто разбираем все проблемы вручную и пытаемся найти наиболее правильное решение. Обычно, оно попадает в одну из следующих категорий:


  • Преднамеренная деградация (например, security fix или новая фича, за которую мы все вместе согласились заплатить производительностью): ничего не делаем
  • Непреднамеренная незначительная деградация: чаще всего нет смысла тратить время на расследование, ничего не делаем
  • Непреднамеренная значительная деградация:
    • Если легко откатить — вмёрдживаем revert commit, после чего спокойно разбираемся в проблеме
    • Если сложно откатить — подключаем всех релевантных разработчиков и пытаемся максимально оперативно пофиксить проблему

По сути, починка вмёрдженной performance-регрессии не особо отличается от починки вмёрдженной обычной регрессии по функциональности: либо откатываем, либо фиксим прямо в master-ветке. Насколько мне известно, принципиально других подходов в индустрии пока не появилось. Единственное отличие performance-регрессий в том, что от них чаще можно отмахнуться и сказать “ну и ладно, не так уж и медленно оно работает, у нас и поважнее задачи есть”, но нужно глубокое понимание продукта для того, чтобы определить ситуации, в которых так сказать действительно можно.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
Россия
Сайт
jugru.org
Численность
51–100 человек
Дата регистрации

Блог на Хабре