NHibernate Profiler - большое расхождение между продолжительностью базы данных и общей продолжительностью?

Question

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

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

Любая идея о том, где я могу начать решать эти проблемы?

Answer 1

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

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

Пример конфигурации для ограничения вывода 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 занимают много времени.

Answer 2

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

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

Удачи

Answer 3

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

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

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

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

Answer 4

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

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

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

С наилучшими пожеланиями,
Маттиас