Обнаружение и определение регрессии производительности

Question

Существуют ли какие-либо известные методы (и связанные с ними ресурсы, такие как исследовательские работы или записи в блогах), которые описывают, как динамически программно обнаруживают часть кода, вызвавшую снижение производительности, и, если возможно, в JVM или в какой-либо другой среде виртуальной машины (где такие методы, как инструментарий, могут быть применены относительно легко)?

В частности, при наличии большой кодовой базы и большего числа коммиттеров для проекта (например, ОС, языка или некоторой инфраструктуры) иногда бывает трудно обнаружить изменения, вызвавшие снижение производительности. Документ, такой как этот , имеет большое значение в описании того, как обнаруживать регрессии производительности (например, в определенном фрагменте кода), но не как динамически найти фрагмент кода в проекте, который был изменен в результате некоторой фиксации и вызвал снижение производительности.

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

Кто-нибудь знает что-нибудь написанное об этом или о каком-либо проекте, использующем такие методы обнаружения регрессии производительности?

EDIT:

Я имел в виду кое-что по этим строкам , но проводил дальнейший анализ самой кодовой базы.

Answer 1

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

Это означало, что при каждой регистрации наш CI-сервер запускал тесты, которые подтверждали, что мы не снижали функциональность за пределами наших допустимых границ.

Он не был идеальным, но он позволял нам со временем следить за нашей ключевой статистикой производительности, а также регистрировал проверки, которые влияли на производительность.

Определение «приемлемых границ» для производительности - больше искусство, чем наука - в наших тестах на основе CI мы использовали довольно простой подход, основанный на спецификации оборудования;мы потерпим неудачу при сборке, если тесты производительности превысили время ответа более 1 секунды при 100 одновременных пользователях.Это вызвало множество проблем с производительностью и дало нам приличный уровень доверия к «производственному» оборудованию.

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

Answer 2

JProfiler позволяет просматривать список инструментальных методов, которые можно отсортировать по среднему времени выполнения, собственному времени, количеству вызовов и т. Д. Я думаю, что если эта информация будет сохранена в выпусках, можно получить представление о регрессии.Несоответствующие данные профилирования не будут точными, если тесты не будут точно такими же.

Answer 3

Некоторым людям известна методика поиска (в отличие от измерения) причины превышения времени.

Это просто, но очень эффективно.

По сути это так:

Если код медленный, это потому, что он тратит часть F (например, 20%, 50% или 90%) своего времени на выполнение чего-то ненужного X в том смысле, что если бы вы знали, что это такое, вы бы взорвали и убери эту долю времени.

В течение общего времени он медленный, в любую случайную наносекунду вероятность того, что он делает X, равна F.

Так что просто загляните в него несколько раз и спросите, что он делает. И спроси, почему он это делает.

Типичные приложения тратят почти все свое время либо на ожидание завершения ввода-вывода, либо на возврат какой-либо функции библиотеки.

Если что-то в вашей программе отнимает слишком много времени (и есть), то это почти наверняка один или несколько вызовов функций, которые вы найдете в стеке вызовов, выполняемых по паршивым причинам.

Вот больше на эту тему .

Answer 4

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

Профилирование производительности - это больше искусство, чем наука. Я не верю, что вы найдете инструмент, который точно скажет вам, в чем проблема, вы должны использовать свое суждение.

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