我已经将这个站点部署到一个共享的主机上，以发现它在不断被回收，因为它们在他们(专用的)应用程序池上设置了100mb的限制。
该网站在释放模式下运行时使用大约110mb RAM。
我试过使用sql Server Express而不是CE，这没有什么区别。
唯一显着的区别是当我完全删除EF(使用假的回购)。内存使用量下降了30〜40mb。一个空白的MVC模板使用大约20mb，所以我认为这不是太糟糕？
“标准”ASP.NET MVC应用程序是否有基准测试？
了解其他EF CTP用户的内存使用情况以及内存分析工具的一些建议(最好是免费的)是很好的。
值得一提的是如何处理EF ObjectContext的生命周期。我正在使用每个请求的会话，并使用StructureMap实例化ObjectContext：
For<IDbContext>().HttpContextScoped().Use(ctx => new MyContext("MyConnStringName"));
非常感谢
本
解决方法
以下是帮助我们的一些事情：
>检查基本信息。确保在发布模式下编译，并在web.config中将编译调试设置为false。很容易忘记这样的事情。
>使用DEBUG符号进行诊断代码。一个例子就是使用NHProf这样的工具(是的，我以前被抓到了)。最简单的方法是将这样的代码包装在#if DEBUG指令中，以确保它不会被编译到应用程序的发行版中。
>不要忘记sql。 ORM使它太容易忽略应用程序与数据库的交互方式。使用sql Profiler或像EFProf / NHProf这样的工具可以准确地显示出正在发生的情况。在EF的情况下，您可能稍后会感到有点不适，特别是如果您大量使用延迟加载。一旦你完成了，你可以开始优化(见下面的一点)。
> Lazy加载是方便的，但不应该在MVC视图(IMO)中使用。这是我们高内存使用的根本原因之一。由于延迟加载(SELECT N 1)，我们网站的主页正在创建59个单独的查询。在为此页面创建一个特定的视图模型之后，我们迫切需要加载我们需要的关联，最多可以在一半时间内执行6个查询。
>设计模式可以引导您，而不是规划应用程序的开发。我倾向于在可能的情况下遵循DDD方法。在这种情况下，我真的不想在我的域模型上公开外键。然而，由于EF不像NH一样处理多对一关联(它将发出另一个查询，只是为了获取我们已经在内存中的一个对象的外键)，我最终得到一个额外的查询(每个对象)显示在我的页面上在这种情况下，我决定为了提高性能，我可以忍受一些代码气味(包括我的模型中的FK)。
>常见的“解决方案”是在性能问题上抛出缓存。在制定缓存策略之前，要确定真正的问题很重要。我可以刚刚将输出缓存应用到我们的主页(见下面的注释)，但这并不改变在缓存到期时我有59个查询数据库的事实。
输出缓存的注释：
当ASP.NET MVC首次发布时，我们可以进行甜甜圈缓存，也就是从特定区域缓存页面APART。事实上，如果您在页面上有用户特定信息，则不再可能使输出缓存变得无用。例如，我们在该网站的导航菜单中具有登录状态。这一点意味着我不能使用输出缓存的页面，因为它也将缓存登录状态。
最终没有一个关于如何优化应用程序的硬规则。当我们停止使用ORM建立我们的协会(面向公众面向我们网站的一部分)时，我们的应用程序性能最大的改进，而不是手动加载到我们的视图模型中。我们无法使用EF热切加载它们，因为有太多的关联(导致一个凌乱的UNION查询)。
一个例子是我们的标记机制。可以标记BlogPost和Project等实体。标签和可标签实体具有多对多关系。在我们的情况下，最好是检索所有标签并缓存它们。然后，我们创建了一个linq投影来缓存可标记实体的关联密钥(例如ProjectId / TagId)。当为我们的页面创建viewmodel时，我们可以为每个可标记实体建立标签，而不会触发数据库。同样，这是针对我们的应用程序，但它在性能方面大大提高，并降低了内存使用量。
我们沿用的一些资源/工具：
> EFProf – 监视由Entity Framework生成的查询(免费试用)
> ANTS Memory Profiler(免费试用)
> Windows性能监视器(perfmon)
> Tess Ferrandez’s blog
>很多咖啡:)
虽然我们做出了改进，这将使我们受到托管公司的(Arvixe)应用程序池限制，我觉得有义务告诉那些正在查看他们的Windows经销商计划的人，这样的限制已经到位(自从Arvixe不在广告计划时提到这一点)。所以当某些东西看起来太好了，不能成为真实的(无限的x，y，z)，它通常是。
