缓存LINQ to SQL DataContext

我们正在为多租户Web应用程序进行一些性能优化。目前，LinqToSql数据上下文是在每个Web请求开始时创建的。上下文对于Web请求具有一定的生命周期，并且使用Castle Windsor将其注入到需要它的任何对象的构造器中。缓存LINQ to SQL DataContext

我们曾想过在会话缓存中缓存上下文（以及一组对象），以便为后续Web请求优化安装成本。这是个好主意吗？需要考虑哪些问题？

2010-07-30 Rob

您是否检查过通过datacontext运行的每个查询以确保最小化数据库IO的消耗？您是否检查了datacontext的调用者以确保重复提取相同的数据不会发生？ – 2010-07-30 18:26:04

@David：调整在探查器中显示为热点的查询。我们的存储库实现可防止反复提取。 – Rob 2010-07-31 00:22:49

一个坏主意IMO。最大的问题是并发性。由于使用连接池，只要您将数据上下文用作数据的管道，而不是数据存储桶本身，成本就没有那么多。

缓存数据;丢弃数据上下文。

试图保留数据上下文此外不扩展到多个服务器，或支持除进程外的任何缓存实现。

你有没有测量安装费用，以便你知道这是否值得考虑？我真的不相信那是你的瓶颈。

2010-07-30 05:41:22

我们已经衡量。这不是创建直流问题，而是附加的数据。我们最初的想法是沿着你的路线，如果它是一个绿地开发的场景，我们肯定会重新加入。在重构上下文之前，我们想要了解如果我们只在短时间内保持dc完好无误，实际上会出现什么问题。 – Rob 2010-07-30 05:45:22

@Rob - 你不应该*在你的数据上下文中需要*数据。它并不意味着*被用作数据存储（甚至包括*身份管理器）。就我个人而言，我会将这些数据移出数据上下文;使用数据上下文来**获取**，但将其缓存在外部。 – 2010-07-30 05:55:28

@Mark - 同意。在绿地方案中，我们将如何处理这个问题。现有的存储库是这样编写的，以便他们假定实体在变更集中，所以我们必须从缓存中补充上下文。当然不是不可能的，这很可能就是我们要做的，但我们想在开发时间有限之前理解所有问题。 – Rob 2010-07-30 06:02:30

回答