От симптома к первопричине: как находить узкие места под нагрузкой
1 декабря, 15:50, «Рио-де-Жанейро»
Мнение Программного комитета о докладе
Система работает что-то небыстро, а железа добавить нельзя, либо оно и вовсе недогружено. Кроме вашего кода, как обычно, куча сторонних компонентов: кафки, редисы, дебезиумы и монги. Денис расскажет, через какой микроскоп вообще на это смотреть.
Целевая аудитория
Инженеры по нагрузочному и нефункциональному тестированию, performance-инженеры, SRE и разработчики высоконагруженных сервисов — все, кто сталкивается с деградацией производительности и ищет системный способ находить первопричины, а не гадать. Также будет полезно техлидам и архитекторам, которым важно понимать, какие метрики слоёв смотреть и в какой последовательности.
Тезисы
В нагрузочном тестировании легко потратить недели и не найти ни одного узкого места: данных много, метрик ещё больше, а связи между ними видны не сразу. В докладе разберём методику, которая позволяет двигаться от гипотезы к первопричине максимально коротким путём. Поговорим о том, на какие метрики серверов приложений, баз данных и брокеров сообщений смотреть и в какой последовательности, чтобы не закопаться в цифрах; какие развилки возникают при анализе причин деградации и как не принять следствие за причину. Отдельно разберём, когда подключаются профилирование и tracing, в каких случаях и кого звать на помощь из команды, а также где в анализе деградации реально работают LLM и machine learning. Всё — на примерах из нагрузочных прогонов.
Спикеры
Сбер
