asp.net-mvc - ASP.NET MVC和EF代码优先内存使用情况

Question

我有一个内置于ASP.NET MVC 3中的应用程序，该应用程序使用SQL CE进行存储，并使用EF CTP 5进行数据访问。

我已经将该站点部署到共享主机上，却发现它不断达到回收利用，因为它达到了（专用）应用程序池上设置的100mb限制。

该站点在发布模式下运行时使用大约110mb RAM。

我尝试使用SQL Server Express而不是CE，但这没有什么区别。

唯一的显着差异是我完全删除了EF（使用伪造的回购协议）时。这将内存使用率降低了30mb-40mb。一个空白的MVC模板使用大约20mb，所以我觉得这还不错吗？

是否有针对“标准” ASP.NET MVC应用程序的基准？

最好了解其他EF CTP用户获得了哪些内存利用率，以及有关内存分析工具（最好是免费的）的一些建议。

值得一提的是我如何处理EF ObjectContext的生命周期。我正在使用每个请求的会话，并使用StructureMap实例化ObjectContext：

For<IDbContext>().HttpContextScoped().Use(ctx => new MyContext("MyConnStringName"));

非常感谢
本

Answer 1

我们确实设法大大减少了内存占用。 IIS worker进程现在位于50mb左右，而之前为100 + mb。

以下是一些对我们有帮助的事情：


检查基础知识。确保在发布模式下进行编译，然后在web.config中将编译调试设置为false。忘记这类事情很容易。
使用DEBUG符号作为诊断代码。例如使用NHProf之类的工具（是的，我之前对此很感兴趣）。最简单的方法是将此类代码包装在#if DEBUG指令中，以确保未将其编译到应用程序的发行版中。
不要忘记SQL。 ORM使忽略应用程序与数据库的通信方式变得非常容易。使用SQL事件探查器或EFProf / NHProf之类的工具可以确切地显示正在发生的事情。对于EF，事后您可能会感到不适，尤其是在您大量使用延迟加载的情况下。一旦解决了这个问题，就可以开始优化（请参见下面的要点）。
延迟加载很方便，但不应在MVC视图（IMO）中使用。这是内存使用率高的根本原因之一。由于延迟加载（SELECT N + 1），我们网站的主页正在创建59个单独的查询。在为该页面创建一个特定的视图模型并急切地加载关联之后，我们需要进行多达一半时间执行的6个查询。
设计模式可以指导您，而不是统治应用程序的开发。我倾向于尽可能采用DDD方法。在这种情况下，我真的不想在域模型上公开外键。但是，由于EF不能像NH那样处理多对一的关联（它将发出另一个查询只是为了获取我们已经在内存中的对象的外键），所以我最后做了一个附加查询（每个对象）显示在我的页面上。在这种情况下，我决定可以忍受一点代码味道（包括模型中的FK），以提高性能。
常见的“解决方案”是对性能问题进行缓存。在制定缓存策略之前，确定真正的问题很重要。我本可以将输出缓存应用于我们的主页（请参见下面的注释），但这并不能改变当缓存过期时我有59个查询命中数据库的事实。


关于输出缓存的注释：
首次发布ASP.NET MVC时，我们可以进行甜甜圈缓存，即从特定区域缓存页面APART。如果页面上有用户特定信息，则不再可能的事实使输出缓存变得毫无用处。例如，我们在网站的导航菜单中具有登录状态。仅此一点就意味着我不能为页面使用输出缓存，因为它还会缓存登录状态。

最终，没有关于如何优化应用程序的严格规则。当我们停止使用ORM来建立我们的关联（针对我们网站的面向公众的部分），而是手动将它们手动加载到我们的视图模型中时，我们应用程序性能的最大改善是。由于关联过多（导致杂乱的UNION查询），我们无法使用EF急切加载它们。

我们的标记机制就是一个例子。可以标记BlogPost和Project之类的实体。标签和可标记实体具有多对多关系。在我们的情况下，最好检索所有标签并对其进行缓存。然后，我们创建了一个linq投影，以缓存可标记实体（例如ProjectId / TagId）的关联键。在为页面创建视图模型时，我们可以为每个可标记实体建立标记，而无需访问数据库。同样，这是特定于我们的应用程序的，但是它在性能和降低内存使用方面产生了巨大的改进。

我们在使用过程中使用的一些资源/工具：


EFProf-监视由Entity Framework生成的查询（提供免费试用版）
ANTS Memory Profiler（提供免费试用版）
Windows性能监视器（性能监视器）
Tess Ferrandez's blog
很多咖啡:)


尽管我们确实进行了一些改进，使我们处于托管公司（Arvixe）应用程序池限制之下，但我确实有责任向正在考虑其Windows经销商计划的人员提供建议，因为这些限制已经到位（因为Arvixe并未这样做）在宣传计划时在任何地方提及此）。因此，当某些东西看起来好得令人难以置信（无限制的x，y，z）时，通常就是这样。