即使进行持久配置优化，流畅的 nHibernate 启动仍然很慢
我们正在尝试减少 Fluent nHibernate 的启动开销。
我们见过的关于这个主题的所有文章（包括这篇文章）都做了以下内容两个建议：
- 在第一次运行时保留配置并随后恢复该配置，而不是重新创建它。
- 确保 ISessionFactory 在应用程序的每个会话中仅创建一次。
我们已经完成了这两项工作，并且在具有 SQLite 后端的双进程 2.8Ghz 64 位 Windows 7 系统上，创建会话工厂的 Fluent nHibernate 启动时间现在约为 550 毫秒。目前只有四个实体，平均每个实体约有六处房产。
这仍然太高了。我们希望将此时间减少到 20 毫秒或更短（这样，即使在较慢的系统上，该时间也会小于 100 毫秒）。我们有可能做到这一点吗？
任何深入了解 Fluent nHibernate 在启动过程中花费如此长的时间所做的事情也会有所帮助。
We're trying to reduce the Fluent nHibernate startup overhead.
All the articles we've seen on this subject (including this one) make the following two suggestions:
- Persist the configuration on the first run and restore that subsequently, instead of re-creating it.
- Make sure the ISessionFactory is created only once per session of the app.
We've done both of these, and the Fluent nHibernate startup time to create the session factory is now around 550ms on a dual-proc 2.8Ghz 64 bit Windows 7 system, with a SQLite backend. There are only four entities at present, with about six properties each on average.
This is still way too high. We'd like to reduce this time to 20ms or less (so that even on slow systems it will be less than 100ms). Is there any likelihood of us being able to do this?
Any insight into what Fluent nHibernate is doing during startup that takes so long will also help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可以使用管理 SessionFactory 的 WCF 服务。由于这独立于您的应用程序，因此启动时间根本不会受到 SessionFactory 的创建的影响。当然，这确实会带来许多其他复杂性（其中之一是延迟加载），但它确实解决了启动时间问题，因为当您启动应用程序时该服务已经在运行。
You could use a WCF service that manages your SessionFactory. Since this is independent of your application the start-up time would not be affected at all by the creation of your SessionFactory. Of course this does bring a number of other complexities (lazy loading for one) to the equation but it does solve your problem of startup time since the service would already be running when you start up your app.