PerfView: анализ производительности приложения, включая вызовы базы данных
В настоящее время я вхожу в PerfView для анализа производительности моих (C#) приложений. Но обычно эти приложения используют много вызовов базы данных. Поэтому я задавал себе такие вопросы, как: - Сколько времени проводится в репозиториях? - (Сколько времени уходит на ожидание возврата SQL-запросов?) -> Я не знаю, возможно ли это обнаружить с помощью PerfView
Но из моих следов я получаю едва ли какие-либо полезные результаты. В представлении "Любые стеки" оно говорит мне (когда я использую группировку в своем репозитории), что 1,5 секунды тратятся в моем репозитории (весь вызов составляет около 45 секунд). И я знаю, что это не совсем так, потому что хранилище называет базу данных много.
Просто метрика ЦП не фиксируется при ожидании завершения SQL-запросов, потому что ЦП не имеет ничего общего в этот период времени, и поэтому мое время просто включает время преобразования данных и т. Д. В хранилище?
Спасибо за любую помощь!
РЕДАКТИРОВАТЬ:
Что я пропустил, так это включил опцию времени потоков, чтобы получить время заблокированного кода (что, как я полагаю, происходит во время вызовов базы данных). Я получил все стеки сейчас, просто отфильтровать неинтересные вещи. Но я, кажется, никуда не денусь.
Что особенно интересно для меня при использовании "Thread Time" - это BLOCKED_TIME. Но с этим, я думаю, время вышло. Когда вы смотрите на скриншот, он говорит мне, что CPU_TIME равен 28,384. Это миллисекунды (afaik), но BLOCKED_TIME составляет 2,314,732, что не может быть миллисекундами. Так что процент CPU_TIME очень низкий - 1,2%, но 28 из 70 секунд все еще много. Так что время включенного процента здесь сравнивает яблоки и апельсины. Может кто-нибудь объяснить?
1 ответ
Итак, мне это удалось.
То, что я пропустил (а Вэнс Моррисон объяснял это в своем видеоуроке): при анализе времени настенных часов с perfview вы получаете накопленное время из всех потоков, которые "ожидают" в том, что называется "BLOCKED_TIME", Это означает, что в течение 70 секунд поток завершителя добавляет 70 секунд к этому "BLOCKED_TIME", потому что он сидел там, ничего не делая (по крайней мере, почти что-либо в моем случае).
Таким образом, при анализе времени настенных часов важно отфильтровать то, что вас интересует. Например, найдите поток, который занимал больше всего времени процессора, и просто включите его в свой анализ, и идите дальше вниз по стеку, чтобы найти части вашего кода, которые дороги (а также могут привести к БД или сервисным вызовам). Как только вы анализируете с точки зрения метода, вы действительно получаете время, которое было потрачено на этот метод, и накопленный "BLOCK_TIME" больше не виден.
Что мне показалось наиболее полезным, так это поиск методов в моем собственном коде, которые "казались трудоемкими", я переключился на представление вызывающих для этого метода. Который проливает некоторый свет от того, где он вызывается, и в представлении вызывающих абонентов, что отвечает за потребление времени дальше вниз по стеку (вызов БД в хранилище или вызов службы для получения некоторых данных).
Немного сложно объяснить, но как только я действительно понял основы анализа времени настенных часов, в какой-то момент все это имело смысл.
Я рекомендую этот видеоурок: http://channel9.msdn.com/Series/PerfView-Tutorial
Опять же, отличный и очень мощный инструмент!