Skip to content
This repository has been archived by the owner on Dec 14, 2018. It is now read-only.

Support output caching #536

Closed
yishaigalatzer opened this issue May 16, 2014 · 14 comments
Closed

Support output caching #536

yishaigalatzer opened this issue May 16, 2014 · 14 comments

Comments

@yishaigalatzer
Copy link
Contributor

We need to design and support output caching for MVC actions. Along with integration to popular caching mechanisms

@tugberkugurlu
Copy link
Contributor

@yishaigalatzer what are the current thoughts on HTTP caching? As MVC is now a unified framework which will also harbor the Web API, that would be something needed there.

@yishaigalatzer
Copy link
Contributor Author

This is currently a need design item. More for tracking a replacement for the old https://aspnetwebstack.codeplex.com/workitem/608 and combine it with the MVC behavior.

That really means we haven't spent much time thinking about it yet. So if you have specific ideas for HTTP caching, it's a good place to add them. We are probably going to break this item down to more fine grained items.

@aliostad
Copy link

As you might know, I have implemented HTTP Caching in CacheCow library. I am happy to contribute towards building the feature.

@Eilon
Copy link
Member

Eilon commented Jun 13, 2014

We're thinking of doing something at the middleware layer so that output caching is available to all other middleware components. Then frameworks such as MVC would merely be consumers of the output caching middleware and not implement any such caching on their own.

@aliostad
Copy link

Well Output Caching is better than nothing but there is more (way more) to HTTP caching than Output Caching.

Output Caching in ASP.NET MVC/Web API is user-mode and not Kernel mode and its rules are usually system-wide (2 requests within 2 minutes or something) and changing them requires registry change. Its capacity bound by the memory available on the server and once threshold reached, it suddenly chucks out half of its content.

I would like to see HTTP caching supported as a first class citizen.

@davidfowl
Copy link
Member

@aliostad whatever we do will likely live in middleware or as part of the HttpAbstractions repository. Mvc will expose those primitives using things like filters.

@aliostad
Copy link

@davidfowl sure. So is there another thread somewhere else that we can carry on discussion?

@nfplee
Copy link

nfplee commented Oct 8, 2014

I look forward to this feature being implemented. I hope it will support Donut Caching where components can be excluded from the parent action's cache.

@danroth27
Copy link
Member

Previously in MVC5 we supported OutputCacheProfiles in Web.config which is a pre-defined set of parameters for OutputCache. This provided a way to reuse the settings in multiple controllers/actions and a centralized place manage all Cache profiles. We do not have an equivalent for this in vNext.

It looked like this:

In Web.config:

<caching>
<outputCacheSettings>
   <outputCacheProfiles>
        <add name="Cache1Hour" duration="3600" varyByParam="none"/>
    </outputCacheProfiles>
</outputCacheSettings>
</caching>

Accessed in the Action like this:

[OutputCache(CacheProfile="Cache1Hour")]
public string Index()
{
    return DateTime.Now.ToString("T");
}

Proposal for vNext:
We can use MvcOptions to achieve the same. It would look something like this:

In Startup.cs

services.Configure<MvcOptions>(options =>
{
    options.CacheProfiles.Add(new CacheProfile() {
         Name =Cache1Hour,
         Duration = 3600,
         VaryByHeader =Accept
    });
});

And my action would look like:

[ResponseCache(CacheProfile="Cache1Hour")]
public string Index()
{
    return DateTime.Now.ToString("T");
}

ResponseCache’s OnActionExecuting will look up the MvcOptions and get the CacheProfile with the particular name and populate the parameters needed to set the headers.

@Tratcher
Copy link
Member

@JunTaoLuo

@RehanSaeed
Copy link

I think there is still some work to do here. The [ResponseCache] only solves half of the problem.

The [ResponseCache] only adds caching HTTP headers and does not actually cache the response like the old [OutputCache] did. We have the cache and distributed-cache tag helpers but these are only useful for MVC views. We also have the IMemoryCache and IDistributedCache services but these will not let you easily cache the response body itself without some effort.

I think there needs to be two attributes [InMemoryCache] and [DistributedCache] which could use the IMemoryCache and IDistributedCache services under the covers. These could have similar properties to the [ResponseCache] including CacheProfileName so that it could be configured elsewhere but with the addition of VaryByParam like the old [OutputCache] did.

@rynowak
Copy link
Member

rynowak commented Jul 18, 2017

Hi, it looks like you are posting on a closed issue/PR/commit!

We're very likely to lose track of your bug/feedback/question unless you:

  1. Open a new issue
  2. Explain very clearly what you need help with
  3. If you think you have found a bug, include detailed repro steps so that we can investigate the problem

Thanks!

@RehanSaeed
Copy link

Just wanted to guage interest from interested parties before I raised another issue. I've raised #6559

@Tratcher
Copy link
Member

How close does https://github.com/aspnet/responsecaching come to fulfilling your in memory caching requirements? It reacts to the headers set by [ResponseCache].

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests