Продолжительность запроса в NHibernate Profiler - PullRequest
0 голосов
/ 30 ноября 2011

У меня есть приложение ASP .Net MVC, которое использует Fluent NHibernate для доступа к базе данных оракула.Я также использую NHibernate Profiler для мониторинга запросов, генерируемых NHibernate.У меня есть один очень простой запрос (выбор всех строк из таблицы с 4 строковыми столбцами).Используется для создания отчета в формате CSV.Моя проблема в том, что выполнение запроса занимает очень много времени, и я хотел бы получить немного больше информации о длительности, отображаемой nhprof.При 65 000 строк это занимает 10-20 секунд, хотя длительность «Только база данных» показывает только около 20 мс.Сетевое отставание не должно разглядеть большую часть этого времени, поскольку серверы находятся в одной гигабитной локальной сети.Я не ожидаю, что люди смогут точно определить для меня, где находится узкое место, но я хотел бы узнать некоторые подробности о том, как читать измерения продолжительности в профилировщике NHibernate.

Что включенов части «Только база данных», а что входит в «Общее время»?Включает ли общее время обработку, выполненную после заполнения объектов C #, так что это время фактически для всего http-запроса?Зная больше об этом, я надеюсь, я смогу устранить некоторые факторы.

Вот как выглядит класс отображения NHibernate:

Table("V_TICKET_DETAILS");

CompositeId()
     .KeyProperty(x => x.TicketId, "TICKET_ID")
     .KeyProperty(x => x.Key, "COLUMN_NAME")
     .KeyProperty(x => x.Parent, "PARENT_NAME");

 Map(x => x.Value, "COLUMN_VALUE");

И запрос, сгенерированный nh profiler, выглядит следующим образом:

SELECT this_.TICKET_ID    as TICKET1_35_0_,
       this_.COLUMN_NAME  as COLUMN2_35_0_,
       this_.PARENT_NAME  as PARENT3_35_0_,
       this_.COLUMN_VALUE as COLUMN4_35_0_
FROM   V_TICKET_DETAILS this_

Представление действительно простое, только объединение двух таблиц с двузначным целым числом.

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

Ответы [ 2 ]

1 голос
/ 01 декабря 2011

Общее время предназначено только для вызова запроса nHib.
Однако оно включает, помимо времени в БД, время, необходимое nHib для заполнения ваших объектов (гидратация).и это, вероятно, ваш виновник.
У меня была аналогичная проблема , возможно, некоторые из предложенных там советов могут вам помочь.

Суть в том, что nHib на самом деле не предназначен для загрузки больших наборов данных.
Если бы ни одно из полученных мной советов не помогло вам, я бы предложил несколько вещей:
1. Маловероятно, чтоВаш пользователь должен просматривать 65 000 строк данных одновременно.возможно, вы сможете найти способ отфильтровать данные так, чтобы набор результатов был меньше (и более читабельным).
2. в противном случае, если, как вы говорите, это «особый» случай, который возникает только при создании отчета- вам не нужно использовать nHib.Вы можете просто использовать, скажем, хорошие старые классы ADO.Net ...

0 голосов
/ 01 декабря 2011

есть также IStatelessSession, который предназначен для таких ситуаций.Он не имеет кеша сессии и экономит много работы.Это должно быть намного быстрее.

using (var session = factory.OpenStatelessSession())
{
}
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...