Метрики производительности по конкретным подпрограммам: какие-либо лучшие практики?

Question

Я хотел бы собрать метрики для конкретных подпрограмм моего кода, чтобы увидеть, где я могу лучше всего оптимизировать. Давайте рассмотрим простой пример и скажем, что у меня есть база данных «Класс» с несколькими «Студентами». Допустим, текущий код вызывает базу данных для каждого учащегося, а не собирает их все сразу в пакете. Мне бы хотелось узнать, сколько времени занимает каждая поездка в базу данных для каждой строки студента.

Это в C #, но я думаю, что это применимо везде. Обычно, когда мне интересно узнать о производительности конкретной подпрограммы, я создаю объект DateTime до его запуска, запускаю подпрограмму, а затем создаю другой объект DateTime после вызова и получаю разницу в миллисекундах между ними, чтобы узнать, как долго она выполняется. , Обычно я просто вывожу это на страницу трассировки ... так что это немного lo-fi. Есть ли лучшие практики для этого? Я думал о том, что смогу перевести веб-приложение в какой-нибудь «диагностический» режим и сделать подробные записи в журнал / запись в журнал событий с тем, что мне нужно, но я хотел посмотреть, есть ли у разума кустарного потока stackoverflow лучшая идея.

Answer 1

Для запросов к базе данных у вас есть две небольшие проблемы. Кэш: кэш данных и кэш операторов.

Если вы выполните запрос один раз, оператор будет проанализирован, подготовлен, связан и выполнен. Данные извлекаются из файлов в кеш.

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

Какой «реальный» номер исполнения? Первый или второй? Некоторые люди говорят, что «наихудший случай» - это реальное число, и мы должны его оптимизировать. Другие говорят «типичный случай» и запускают запрос дважды, игнорируя первый. Другие говорят «средний» и бегают в 30 раз, усредняя их всех. Другие говорят «типичное среднее», бегите 31 раз, а среднее - последние 30.

Я полагаю, что «последние 30 из 31» являются наиболее значимым числом производительности БД. Не переживайте то, что вы не можете контролировать (анализировать, готовить, связывать) раз. Потте все, что вы можете контролировать - структуры данных, загрузка ввода / вывода, индексы и т. Д.

Answer 2

Я иногда использую этот метод и считаю его довольно точным. Проблема заключается в том, что в больших приложениях с довольно большим количеством отладочных журналов поиск информации в журналах может быть затруднительным. Поэтому я использую внешние инструменты (я программирую в основном на Java и использую JProbe), которые позволяют мне видеть среднее и общее время для моих методов, сколько времени затрачивается исключительно определенным методом (в отличие от совокупного времени, потраченного этим методом). и любой метод, который он вызывает), а также распределение памяти и ресурсов.

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

Answer 3

Некоторые подходы, которые вы выберете, позволят вам лучше оценить производительность вашего приложения. Одна вещь, которую я могу порекомендовать, это использовать System.Diagnostics.Stopwatch вместо DateTime, DateTime точен только до 16 мс, где секундомер точен до такта процессора.

Но я рекомендую дополнить его пользовательскими счетчиками производительности для производства и запуска приложения под профилировщиком во время разработки.

Answer 4

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

Тот, который я использую, JProfiler , работает в мире Java и может подключаться к уже запущенному приложению, поэтому никаких специальных инструментов не требуется (по крайней мере, для более новых JVM).

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

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

Я никак не связан с ej-технологиями, кроме как очень счастливый клиент.

Answer 5

Если вы работаете с .NET, то я бы рекомендовал проверить класс Секундомер . Время, которое вы получите от этого, будет гораздо более точным, чем эквивалентный образец, использующий DateTime.

Я бы также рекомендовал проверить ANTS Profiler для сценариев, в которых производительность исключительно важна.

Answer 6

Есть несколько Профилировщиков , но, честно говоря, я думаю, что ваш подход лучше. Подход профилировщика является излишним. Возможно, использование профилировщиков стоит проблем, если вы абсолютно не знаете, где находится узкое место. Я предпочел бы потратить немного времени на анализ проблемы и представить несколько стратегических операторов печати, а не выяснить, как настроить ваше приложение для профилирования, а затем пролить гигантские отчеты, в которых синхронизируется каждая исполняемая строка кода.

Answer 7

Я думаю, у вас хороший подход. Я рекомендую вам создавать «дружественные к машине» записи в файлах журналов, чтобы вам было легче их анализировать. Что-то вроде CSV или других записей с разделителями, которые последовательно структурированы.

Answer 8

Я использую этот метод и думаю, что он очень точный.