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

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

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

alt text

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

Ответы

Ответ 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 занимают много времени.

Ответ 2

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

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

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

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

Ответ 3

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

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

Удачи.

Ответ 4

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

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

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

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