Fluent nHibernate 启动仍然很慢，即使进行了持久的配置优化答案

【问题标题】：Fluent nHibernate Startup still slow even with persistent configuration optimizationFluent nHibernate 启动仍然很慢，即使进行了持久的配置优化
【发布时间】：2011-04-17 22:25:51
【问题描述】：

我们正在尝试减少 Fluent nHibernate 启动开销。

我们看到的所有关于这个主题的文章（包括this one）都提出了以下两个建议：

在第一次运行时保留配置并随后恢复，而不是重新创建。
确保在应用的每个会话中只创建一次 ISessionFactory。

我们已经完成了这两项工作，在具有 SQLite 后端的双进程 2.8Ghz 64 位 Windows 7 系统上，创建会话工厂的 Fluent nHibernate 启动时间现在约为 550 毫秒。目前只有四个实体，平均每个实体大约有六个属性。

这还是太高了。我们希望将这个时间减少到 20 毫秒或更短（这样即使在慢速系统上也将小于 100 毫秒）。我们有没有可能做到这一点？

了解 Fluent nHibernate 在启动过程中花费了这么长时间所做的工作也将有所帮助。

【问题讨论】：

“任何了解 Fluent nHibernate 在启动期间执行的操作需要这么长时间也会有所帮助” - 您查看过日志文件吗？ NH+F 做了很多日志记录，你可以看到在哪里花费的时间最多
你的方案是什么？如果这种情况只发生一次（这是正常情况），那么每秒 1/2 是否很重要？在大多数情况下，您不应在每个应用程序生命周期内多次创建 ISessionFactory。
@UpTheCreek：是的，正如解释的那样，这只发生一次。这非常重要，因为它会影响应用程序的响应能力。此外，这是一个非常快的系统，在较慢的系统上运行会更糟，甚至可能更糟。我们知道如何通过让应用程序的其余部分并行启动来呈现响应的错觉，但这半秒真的很痛苦（抱歉，这是表达焦虑的唯一方法。）跨度>
我就是这种情况，我想你可能要求太多了。也许您可以通过放弃自动映射（如果您正在使用它）或完全放弃 fluent 并使用标准 xml 映射文件来稍微加快 ISessionFactory 的创建速度。但是，如果您需要快速启动，那么 ORM 可能不是合适的选择。
@UpTheCreek：在这种大小的机器上 550 毫秒确实是永恒的，这就是为什么我们挠头想知道 NH+F 在做什么。希望一个好心人能让我们摆脱这种特殊的痛苦。我们还将查看@IgorBrejc 建议的日志文件。

标签： nhibernate sqlite windows-7 fluent-nhibernate

【解决方案1】：

您可以使用管理 SessionFactory 的 WCF 服务。由于这与您的应用程序无关，因此启动时间根本不会受到创建 SessionFactory 的影响。当然，这确实会给方程式带来许多其他复杂性（其中之一是延迟加载），但它确实解决了您的启动时间问题，因为在您启动应用程序时服务已经在运行。

【讨论】：

如果一切都失败了，这是一个合理的想法。然而它真的很复杂——另一个二进制文件、安装服务等。我们的目标是一个也可以从闪存驱动器运行的 xcopy-deploy 项目。