Свободный запуск nHibernate по-прежнему медленный даже при постоянной оптимизации конфигурации

Мы пытаемся уменьшить накладные расходы на запуск Fluent nHibernate.

Все статьи, которые мы видели по этой теме (включая эту), делают следующее два предложения:

  1. Сохраните конфигурацию при первом запуске и восстановите ее впоследствии, вместо того, чтобы создавать ее заново.
  2. Убедитесь, что ISessionFactory создается только один раз за сеанс приложения.

Мы сделали и то, и другое, и время запуска Fluent nHibernate для создания фабрики сеансов теперь составляет около 550 мс в двухпроцессорной 64-битной системе Windows 7 с частотой 2,8 ГГц и серверной частью SQLite. В настоящее время существует всего четыре предприятия, в каждом из которых находится в среднем около шести объектов недвижимости.

Это все еще слишком много. Мы хотели бы уменьшить это время до 20 мс или меньше (чтобы даже в медленных системах оно было меньше 100 мс). Есть ли вероятность, что мы сможем это сделать?

Любое понимание того, что делает Fluent nHibernate во время запуска, которое занимает так много времени, также поможет.


sqlite windows-7 nhibernate fluent-nhibernate
person bright    schedule 17.04.2011    source источник
comment
Любое понимание того, что делает Fluent nHibernate во время запуска, который занимает так много времени, также поможет - вы смотрели файл журнала? NH + F много ведет журналы, и вы можете увидеть, на что тратится больше всего времени.   -  person Igor Brejc    schedule 17.04.2011
comment
Каков ваш сценарий? Если это случается только один раз (что является нормальной ситуацией), то имеет ли значение 1/2 секунды? В большинстве сценариев вы не должны создавать ISessionFactory более одного раза за время существования приложения.   -  person UpTheCreek    schedule 17.04.2011
comment
@UpTheCreek: Да, как уже объяснялось, это происходит только один раз. Это очень важно, потому что влияет на скорость отклика приложения. Вдобавок это очень быстрая система, и работать на более медленной системе будет хуже, а возможно, и намного хуже. Мы знаем, как представить иллюзию отзывчивости, запустив остальную часть приложения параллельно, но эти полсекунды - настоящая заноза в заднице (извините, но это единственный способ выразить беспокойство здесь).   -  person bright    schedule 17.04.2011
comment
В том случае, я думаю, вы слишком многого от него просите. Возможно, вы сможете сделать создание ISessionFactory немного быстрее, отказавшись от автоматического сопоставления (если вы его используете) или полностью отказавшись от использования стандартных файлов сопоставления xml. Однако, если у вас есть потребность в молниеносном запуске, возможно, ORM не подходит.   -  person UpTheCreek    schedule 17.04.2011
comment
@UpTheCreek: 550 мс на машине такого размера - это действительно вечность, поэтому мы ломаем голову над тем, что делает NH + F. Надеюсь, добрый самаритянин избавит нас от этого несчастья. Мы собираемся посмотреть файлы журналов, которые предложил @IgorBrejc.   -  person bright    schedule 17.04.2011

Ответы (1)


arrow_upward
0
arrow_downward

Вы можете использовать службу WCF, которая управляет вашей SessionFactory. Поскольку это не зависит от вашего приложения, создание SessionFactory никак не повлияет на время запуска. Конечно, это вносит в уравнение ряд других сложностей (например, ленивую загрузку), но это решает вашу проблему времени запуска, поскольку служба уже будет запущена, когда вы запустите свое приложение.

person Cole W    schedule 17.04.2011
comment
Это разумная идея, если ничего не помогает. Однако это действительно довольно сложно - еще один двоичный файл, установка службы и т. Д. Мы нацелены на проект xcopy-deploy, который также можно запускать с флэш-накопителя. - person bright; 17.04.2011