Hello.

I have implemented the menu in the project, and saved it in the MS SQL Server . Each time a new page is loaded, the getMenuItemAndSerialize() method retrieves from the database, and displays menu items on the page, respectively, by role.

In List<some_object> not to extract data from the database each time, I decided to save the List<some_object> in ASP.NET Session State . The size of the object stored in the session reaches a maximum of 13 kb. Do you think that 13 Kb is not much for one session?

Is there a better solution and reference to the implementation?

Thank you in advance.

  • 2
    And the Russian word "permissions" is not more-suitable instead of the word "permission"? - Dex
  • I just thought the word hash is also of Russian origin, so I continued in the same spirit. Remark accepted, edit the text for the better)) - loviji

1 answer 1

Using caching, you can reduce the number of database accesses, optimize query processing and thereby reduce server load and improve performance.

The easiest way to cache data is using the OutputCache attribute.

This attribute can be applied to the entire controller, as well as to its individual methods. Applying an attribute to a controller allows you to set a uniform caching policy for all methods of a given controller.

The action of the OutputCache attribute can be configured using its properties:

  • CacheProfle : defines caching configuration
  • Duration : content caching duration in seconds. It is important to choose the optimal time interval, because if you set a large value, users will work with almost static data, and at a very small value, the cache will be updated too often, which eliminates the advantages of using it
  • Location : The location where the cached content is located.
  • NoStore : if this value is true, the no-store flag is set in the response in the Cache-Control header, which indicates to the browser that the content should not be saved
  • SqlDependency : defines the relationship between the cache and the table in the database
  • VaryByCustom : specifies an arbitrary value by which different versions of cached data will be determined.
  • VaryByHeader : specifies a set of headers that will determine the different versions of the cached data
  • VaryByParam : indicates the parameters of the query string or the parameters of the submitted forms, which will determine the different versions of the cached data

Using the Location property, you can define both a server and a client browser as a storage for cached content. In particular, this property can take one of the values ​​of the System.Web.UI.OutputCacheLocation enumeration:

  • Any : the content is cached both on the client and on the proxy server and in the server output cache
  • Client : content is cached on the client (in the browser)
  • Downstream : the content is cached both on the client and on the proxy server. Server output cache not used
  • None : the Cache-Control header is set to no-cache, which means that the content will not be cached anywhere.
  • Server : content is cached only in server output cache
  • ServerAndClient : the content is cached on the client and in the output cache of the server

Example:

 using System; using System.Collections.Generic; using System.Linq; using System.Web; using System.Web.UI; using System.Web.Mvc; namespace CachingApp.Controllers { public class HomeController : Controller { static int x = 9; [OutputCache(Duration=30, Location= OutputCacheLocation.Downstream)] public string Index() { x++; return x.ToString(); } } }

For simplicity, the example in this case is displayed in the browser the value of a static variable. In normal operation without caching, each time this method was accessed, the value of this variable would increase by one. But here the OutputCache attribute is used, which sets, firstly, the caching time - 30 seconds, secondly, the cache location is the client and the forward proxy servers through which the request can go.

As a result, despite the new calls to the resource within 30 seconds, we will receive the same value of the variable x, because its value will be taken from the cache. And only in 30 seconds this variable can be incremented.

We can inspect the response headers in the browser (for example, in IE):

enter image description here

When we receive the cached data, we will receive the status code 304, and the time spent on the request will be very short (in this case no more than 1 ms), since the data will be taken from the browser cache.

Similarly, we can limit caching to the server:

 public class HomeController : Controller { static int x = 9; [OutputCache(Duration=30, Location= OutputCacheLocation.Server)] public string Index() { x++; return x.ToString(); } }

Same method, only caching is limited to server cache. Unlike the previous example, here the request goes from the browser to the server, but after caching for the next 30 seconds when the method is called again, this method will not work: it will simply give the client the data that is in the cache:

enter image description here

With repeated calls, again, the time is rather short - in this case, only 15 milliseconds.

Although the execution time of this method is very short due to its simplicity — a simple increment of a variable, but in reality, the methods will naturally be much more difficult, with a selection from the database, accessing various resources and complex calculations. And here caching can really optimize server performance.

Taken here