NHibernate Profiler - большое расхождение между продолжительностью базы данных и общей продолжительностью? - PullRequest
11 голосов
/ 07 января 2011

У меня есть приложение, которое широко использует NHibernate.Я начал использовать NHibernate Profiler для выявления возможных проблем с производительностью.Мой вопрос связан со статистикой продолжительности запросов.

Статистика разбита на Длительность базы данных и Общая продолжительность.Из того, что я прочитал, цифры должны быть очень близки.Однако я вижу относительно большие различия и пытаюсь выяснить их источник.Вот некоторые данные

alt text

Есть идеи, где я могу начать исправлять эти проблемы?

Ответы [ 4 ]

6 голосов
/ 15 сентября 2011

Использует ли ваше приложение log4net? Если это так, вам следует проверить конфигурацию log4net и уменьшить объем данных, которые вы регистрируете из NHibernate.

Пример проекта, над которым я сейчас работаю: для запроса, возвращающего 60 строк / объектов, запись всех сообщений журнала NHibernate на уровне DEBUG в файл увеличивает общую продолжительность сообщения NHProf с 8 мс до примерно 8000 мс! 1003 *

Пример конфигурации для ограничения вывода NHibernate:

<root>
    <level value="ALL" />
    <appender-ref ref="console" />
    <appender-ref ref="trace" />
</root>

<logger name="NHibernate">
    <level value="WARN" />
</logger>

Если это не решит вашу проблему, возможно, вы могли бы использовать инструмент профилирования производительности, такой как dotTrace или ANTS Profiler, для выявления потенциальных узких мест в вашем коде. Это даст вам четкое представление о том, какие методы в коде вашего / NHibernate занимают много времени.

0 голосов
/ 07 января 2011

Я не знаю это точно, но я всегда предполагал, что Общая длительность добавляет все накладные расходы NHibernate при создании запроса SQL и при извлечении данных - при создании объектов с необработанными данными.

Возможно, процесс строительства с вашими сущностями очень медленный? Есть ли у вас обширная обработка в ваших сущностях конструкторов? любые операции ввода-вывода, ведение журнала, дополнительный доступ к БД, использование сети ...

Удачи

0 голосов
/ 18 мая 2011

Первый результат - это время, которое потребовалось для выполнения и получения результата из БД. Второй результат - это время, необходимое NHibernate для загрузки соответствующих объектов в память.

Я сейчас работаю в проекте, который использует очень большую сущность (почти 100 столбцов / полей). Если я попытаюсь загрузить пару тысяч, это также займет несколько секунд. Однако sql-запрос вернет список идентификаторов сущности за несколько миллисекунд. Но чтобы на самом деле загрузить эти идентификаторы в соответствующие объекты, генерируются дополнительные издержки, если ваши объекты являются большими или сложными объектами (см. Пост выше).

Получаете ли вы какие-либо оповещения о сгенерированных запросах? Столбец рядом с полем Продолжительность в NHibernate Profiler.

С уважением,
Маттиас

0 голосов
/ 07 января 2011

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

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

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

Надеюсь, это поможет.

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