5

I am going through a tutorial in ASP.Net MVC 5 and I learned about caching. But I could not understand what determines whether I should cache at client or server.

Here is the code snippet.

For client:

[OutputCache(Duration = 86400, Location = OutputCacheLocation.Client)]
public ActionResult SelectLocation()
{
}

For server:

[OutputCache(Duration = 86400, Location = OutputCacheLocation.Server)]
public ActionResult SelectLocation()
{
}

Question: Can someone tell me when I should apply client caching and when should I use the server one. And the downside or any consequences I should look for?

ssmith
  • 8,092
  • 6
  • 52
  • 93
Unbreakable
  • 7,776
  • 24
  • 90
  • 171
  • If your system has sensitive data than i dont recommend to use caching this way. For client caching, data will remain available on browser even after session times out. – Houssam Hamdan Apr 27 '17 at 14:37

5 Answers5

3

In regards to OutputCache, "client" caching simply means that cache-control headers and/or an expires header will be sent with the response, indicating that the client may cache the document. Typically, the client, especially if it's a web browser, will choose to do so. It then will not need to make a new request if the same resource is needed again. However, the browser may still occasionally make a HEAD request just to check if there's a new version of the resource.

"Server" caching means, still in regards to OutputCache, that the server will cache the response locally, usually in memory. This means that as long as the cache is still valid, the server will not actually render the action again, but rather, will just serve up the cached resource, instead.

The main difference, then, between the two is that the server cache will be used for all requests for that resource, regardless of what client is currently making the request, while client cache will obviously just be limited to that one particular client. The server will not need to render the action again for that client, but will for the next client that comes along.

However, the default is Any, which includes server and client caching (as well as other locations). In other words, server and client caching are not mutually exclusive, and usually you'd do both to minimize both the work the server needs to do and the amount of requests it needs to respond to.

Chris Pratt
  • 232,153
  • 36
  • 385
  • 444
0

Have a look here. It is very nicely explained

By default, content is cached in three locations: the web server, any proxy servers, and the user's browser. You can control the content's cached location by changing the location parameter. When you cache on the server, every user receives the same content and when it is only client side, the cached content differs by users.

The location parameter has the default value Any which is appropriate for most the scenarios. But some times there are scenarios when you required more control over the cached data.

Suppose you want to cache the logged in use information then you should cached the data on client browser since this data is specific to a user. If you will cached this data on the server, all the user will see the same information that is wrong.

You should cache the data on the server which is common to all the users and is sensitive.

Ivan Mladenov
  • 1,787
  • 12
  • 16
0

One point of view could by the cache invalidation scenario. When caching on the client side, you'd need to adjust the URL the client hits to avoid cache hit / force recalculation of response. When caching on the server side, you might invalidate the cached content easier. See this question: How to programmatically clear outputcache for controller action method

Community
  • 1
  • 1
Varga Tamas
  • 66
  • 4
0

As described in https://msdn.microsoft.com/en-us/library/system.web.ui.outputcachelocation(v=vs.110).aspx

Client will instruct browser to cache html in it's own cache. Pros: faster since it is cached on browser, does not take up server memory. Cons: it is dependable on user browser settings (cache size, expiration etc.) and user can delete on it's own

Server will keep cached html on server Pros: does not depend on browser rules since it sends no-cache, you control the cache, not user. Cons: slower then client since it will always include transport, takes up server memory

chehh984
  • 121
  • 4
0

The reason that there are a variety of options when dealing with cache control is simple; there is no universal correct answer that is applicable to all sites.

A "business card" site that is pretty static in it's design and content as well as being the only site on the server could pretty much be set to cache it everywhere for an infinite time period. However, if that server is actually hosting a thousand sites then we start have to worry about the server cache and its viability because IIS will start dumping cache items if the memory gets low, so we may not want that server cache.

If we have an ecomm site that is very high traffic with product changes and additions on an hourly basis, we would want to reduce the max-age so that the content remains up to date. But then again, the content generation for these more demanding applications can slow the server down due to all of the dynamic content processing, especially if this site is on a shared server.

There are plenty of resources on the general internet, MSDN, and here that you can review to help you determine on what is best for you. With the wide variety of sites that I have worked with in single and shared environments I have most as Server and client locations, some will use the Last-Modified header and others use eTag.

Mad Myche
  • 1,075
  • 1
  • 7
  • 15