视图中的对象缓存或输出:哪个更好?

时间:2010-05-29 15:38:40

标签: asp.net asp.net-mvc performance caching

我在ASP.Net MVC中有一个电子商务。我正在使用缓存来提高页面的性能并且它正在运行。

我想知道什么可以提供更好的性能,例如,我可以在我的视图中设置OutputCache,并将此缓存用于所有页面 OR 我可以在控制器中获取我的产品列表,把它放在缓存上(如下面的代码)并将其发送到View以呈现给用户?

private IEnumerable<Products> GetProductsCache(string key, ProductType type)
        {
            if (HttpContext.Cache[key] == null)
                HttpContext.Cache.Insert(key, ProductRepository.GetProducts(type), null, DateTime.Now.AddMinutes(10), Cache.NoSlidingExpiration);

            return (IEnumerable<Products>)HttpContext.Cache[key];
        }

public ActionResult Index()
        {
            var home = new HomeViewModel()
                           {
                               Products = GetProductsCache("ProductHomeCache", ProductType.Product)
                               Services = GetProductsCache("ServiceHomeCache", ProductType.Service)
                           };

            return View(home);
        }

两者都有效,但我想知道提高性能的首选方法是什么,还是有其他更好的方法可以做到这一点?

3 个答案:

答案 0 :(得分:2)

在你的例子中,正如Ivan所指出的那样,输出缓存在性能方面会略好一些。但只是略有一点。

根据我的经验,大部分性能提升来自数据缓存。页面处理是一种相对便宜的操作,但数据库调用不是。因此,我总是将我的数据gzip并将其转储到缓存中,当我将其从缓存中取出时会膨胀。如果您感兴趣,Hanselman有一个很好的压缩缓存示例:http://www.hanselman.com/blog/CommentView.aspx?guid=aa479008-3d1e-45fc-b89f-e9c2ffc199c1

此外,mvc中的输出缓存可能有点棘手。要缓存整个页面是可以的,只需使用[OutputCache]属性即可。但是,如果您只想缓存部分(大部分时间都是这样),它会变得更复杂一些。

缓存有望MS在mvc 3中有所改进。

答案 1 :(得分:1)

OutputCache将提供更好的结果。但并不总是可以使用 - 例如,如果您有许多动态(用户特定)控件。

多个视图中使用结果集时,也可以选择缓存结果。您当前的实现是缓存安全 - 即如果两个或多个线程同时进入if,哪一个将在保存结果时获胜?如果您选择这种方式,请使用 ReaderWriterLockSlim 保护您的缓存。

另外要注意选择缓存时间!我建议您使用缓存能力构建应用程序,但不要缓存除非完全确定需要花费大量时间执行(可能是您的方法需要改进吗?)。项目准备好后,对其进行概要分析,并将缓存放在仅需要的地方!

但我建议你先调查一下 - 即在给定情况下哪一个更适合你。不要过度使用一个,不要过度使用它们!

答案 2 :(得分:1)

在真正的ASP.NET MVC站点中,您几乎没有机会使用OutPutCache。

问题是没有保存方式来使用甜甜圈缓存。这意味着您缓存了大部分页面,但是有一些您没有缓存的特定于用户的部分。这适用于旧学校的ASP.NET。

菲尔·哈克(Phil Haack)写了关于甜甜圈缓存的文章,但结果证明在MVC2中不可行 http://haacked.com/archive/2008/11/05/donut-caching-in-asp.net-mvc.aspx

我经常开始使用OutputCaching而不考虑每个人都忘记的这个小用户特定细节。

你可能会想:我可以通过做一些加载动态数据的Javascript来解决这个问题......面对公众网站的坏主意。有非JavaScript客户端,还有谷歌机器人。

首先,我感到害怕,这可能会导致我们的高流量网站崩溃:但通过将调用结果缓存到数据层中,它可以很好地工作。