Fluent nHibernate Стартирането все още е бавно дори при постоянна оптимизация на конфигурацията

Опитваме се да намалим разходите за стартиране на Fluent nHibernate.

Всички статии, които сме виждали по тази тема (включително тази) правят следното две предложения:

  1. Запазете конфигурацията при първото изпълнение и я възстановете впоследствие, вместо да я създавате отново.
  2. Уверете се, че ISessionFactory се създава само веднъж на сесия на приложението.

Направихме и двете и времето за стартиране на Fluent nHibernate за създаване на фабриката за сесии сега е около 550 ms на двойна система 2,8 Ghz 64 бита Windows 7 с SQLite бекенд. В момента има само четири субекта, средно с около шест имота всеки.

Това все още е твърде високо. Бихме искали да намалим това време до 20 ms или по-малко (така че дори при бавни системи да бъде по-малко от 100 ms). Има ли някаква вероятност да успеем да направим това?

Всяко вникване в това какво прави 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 малко по-бързо, като премахнете автоматичното картографиране (ако използвате това) или като премахнете напълно fluent и използвате стандартни файлове за картографиране xml. Въпреки това, ако имате изискване за светкавично бързо стартиране, тогава може би ORM не е подходящ избор.   -  person UpTheCreek    schedule 17.04.2011
comment
@UpTheCreek: 550ms на машина с такъв размер са наистина цяла вечност, поради което се чешем по главите, чудейки се какво прави 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