PerfView: анализ производительности приложения, включая вызовы базы данных

Question

Я вхожу в PerfView для анализа производительности для своих приложений (C#). Но обычно эти приложения используют множество запросов к базе данных. Итак, я задал себе следующие вопросы: - Сколько времени потрачено на репозитории? - (Сколько времени уходит на ожидание возврата SQL-запросов?) -> Я не знаю, можно ли это открыть с помощью PerfView

Но из моих следов я получаю практически ничего полезного. В представлении «Any Stacks» это говорит мне (когда я использую группировку в моем репозитории), что 1,5 секунды потрачено на мой Repsoitory (весь вызов составляет около 45 секунд). И я знаю, что это не так, потому что репозитории называет базу данных LOT.

Является ли это то, что показатель ЦП не учитывается при ожидании завершения SQL-запросов, потому что CPU не имеет ничего общего с этим периодом времени, и поэтому мои времена включают в себя только время преобразования данных и т. Д. В репозиторий?

Спасибо за помощь!

EDIT:

Что я пропустил превращаюсь в варианте раза нити, чтобы получить времена заблокированного кода (что то, что происходит во время обращений к базе данных я полагаю). Теперь у меня есть все стеки, просто отфильтруйте неинтересные вещи. Но я, кажется, никуда не денутся.

Что особенно интересно для меня при использовании «Thread Time» - это BLOCKED_TIME. Но с этим время я думаю. Когда вы смотрите на скриншот, он сообщает мне, что CPU_TIME составляет 28 384. Что такое миллисекунды (afaik), но BLOCKED_TIME составляет 2 314 732, что не может быть миллисекундами. Так что процент для CPU_TIME очень низкий с 1,2%, но 28 из 70 секунд по-прежнему много. Таким образом, время Inclusive Percentage сравнивает яблоки и апельсины здесь. Может кто-нибудь объяснить?

Answer 1

Итак, я преуспел.

Что я пропустил (и Vance Morrison объяснял это в своем видеоуроке): когда вы выполняете анализ времени настенных часов с помощью perfview, вы получаете накопленное время со всех потоков, которые «ожидают» в том, что «BLOCKED_TIME». Это означает, что в течение 70 секунд, только поток финализатора добавляет 70 секунд к этому «BLOCKED_TIME», потому что он сидел там, ничего не делая (по крайней мере, почти что-либо в моем случае).

Поэтому, когда вы выполняете анализ времени настенных часов, важно отфильтровать то, что вас интересует. Например, найдите поток, который занимает наибольшее время CPU, и просто включите его в свой анализ и идите дальше вниз стек, чтобы найти фрагменты вашего кода, которые являются дорогостоящими (а также могут привести к DB или служебным вызовам). Как только вы анализируете с точки зрения метода, вы действительно получаете время, потраченное на этот метод, и накопленный «BLOCK_TIME» не соответствует действительности.

Что я нашел наиболее полезным, это поиск методов в моем собственном коде, который «казался трудоёмким», и я переключился на представление вызывающих абонентов для этого метода. Который пролил некоторый свет от того, где он вызван, и в опросах видят, что отвечает за время потребления дальше по стеку (вызов БД в репозитории или служба вызывает получение некоторых данных).

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

Я рекомендую этот видеоурок: http://channel9.msdn.com/Series/PerfView-Tutorial

Опять же, большой и очень мощный инструмент!