About the use of Cookie,session,cache in cache

Article Source: http://canann.iteye.com/blog/1941173

There are many ways to cache data previously, there are client cookies, server-side session and application.

Where a cookie is a set of data that is stored on the client and is used primarily to store personal information such as user names.

The session saves the conversation information. Application is the information that is stored throughout the application and is equivalent to a global variable.

Session

Session is used to save each user's proprietary information

The lifetime of the session is the duration of the user's continuous request plus a period of time (typically 20 minutes or so)

Session information is stored in the Web server memory, the amount of data saved can be very small
This method is inefficient because it remains in memory for a period of time after the user stops using the application

Code:

Session[“UserID”]=”test”;
String UserName=Session[“UserID”].ToString();

Cookies

Cookies are used to store request information for client browser request Server Pages

We can store non-sensitive user information, save time can be set as required

If the cookie expiration date is not set, its life cycle is saved until the browser is closed

The Expires property of the cookie object is set to MinValue means never expires

The amount of data stored by a cookie is limited, and most browsers are 4K so don't store big data

Since not all browsers support cookies, the data is stored in clear text in the client

Code:

Resopnse.Cookies[“UserID”]=”test”;
String UserName= Resopnse.Cookies [“UserID”].ToString();

Cache

Cache is used to save pages or data during HTTP requests

The use of the cache can greatly improve the efficiency of the entire application.

It allows frequently accessed server resources to be stored in memory, and when the user makes the same request, the server is not processed again, but the data saved in the cache is returned directly to the user

You can see that the cache saves time-server processing time

The cache instance is proprietary to each application, its lifecycle = = the application cycle

Application restart will recreate its instance

Note: You must use the Insert or Add method method to add information if you want to use cached cleanup, expiration management, dependencies, and so on

Code:

Cache[”ID”]=”cc”;或者Cache.Insert(“ID”,”test”);
String ID =Cache[“ID”].ToString();

What is the difference between a session and a cache when the session is usually most frequently used?

The difference between session caches and cache caches.

(1) The biggest difference is that the cache provides caching dependencies to update the data, and the session can only rely on the defined cache time to determine if the cached data is valid.

(2) Even if the application terminates, the cached data will persist the next time the application is opened, as long as the cache time defined in the Cache.Add method has not expired. The session cache exists only in one session, and the data is invalidated after the conversation is over.

(3) The session is easily lost, resulting in uncertainty in the data, and the cache does not appear in this situation.

(4) because the session is loaded every time, so it is not appropriate to store a lot of information, otherwise it will cause the server performance degradation. The cache is used primarily to hold large volumes of information, such as multiple tables in a database.

(5) session is currently only stored in memory and has an impact on its performance.

Session: Provides information for the current user session. It also provides access to the session-scoped cache that can be used to store information, as well as ways to control how the session is managed. It is stored in the server's memory, so it executes faster than storing and retrieving information in the database. Unlike application states that are not specific to a single user session, session state is applied to individual users and sessions. As a result, application state is ideal for storing common data that is small in number and varies with the user.      And because it does not occur server-client data transfer, the session is also suitable for storing security data about the user, such as shopping cart information. The key features of the session are: stored in server memory, session-related, the entire lifetime of the conversation will not be actively discarded, not serialized, server-client data transfer does not occur.
Cache: It is stored in the server's memory, allowing you to customize how items are cached and how long they are cached. For example, when there is a lack of system memory, the cache automatically removes less-used or lower-priority items to free up memory. This technique is also known as cleanup, which is one of the ways that caching ensures that outdated data does not use valuable server resources. It is not related to sessions, so it is multi-session shared, so using it can improve site performance, but it may reveal user security information, and because the cache may be automatically removed when the server lacks memory, you will need to detect if the cache entry exists every time you fetch the data. The key features of the cache are: stored in server memory, session-independent, depending on the state of the server memory resources can be discarded at any time, not be serialized, server-client data transfer does not occur.

Cookie:cookie provides a way to store user-specific information in a WEB application. For example, you can use cookies to store user preferences or other information when a user accesses your site. When the user accesses your site again, the application can retrieve previously stored information. When developers programmatically set cookies, they need to serialize the data they want to save into strings (and note that many browsers have a 4096-byte limit on cookies) and then set them.

Key features of cookies are: stored on the client hard disk, related to the user, persistent storage for a certain period of time, can share data across browsers, need to be serialized, the server-client data transfer occurs. The following question is very enlightening: recent team colleagues like to use the session to do page jump, specifically in the query page to put the query results in a DataTable, the session stored the DataTable, read to the data after the sub-page to do the session cleanup, Does this have any effect on performance?
1, session:session indeed is stored in the server's memory (but not the 4k upper limit, the specific size limit should be server memory), and the same SessionID multiple HTTP requests will be queued, that is, the session is synchronized to the same browser, Performance is greatly affected by poor use. In addition, the session relies on the client cookie, because SessionID is stored in the client browser process cookie, so the browser does not support cookies, the session will also be lost (session URL rewrite can partially solve the problem, Refer to: HTTP://WWW.SUNGNESS.COM/ARCHIVES/48). It is therefore not recommended to use.

2. Cookies are also not recommended for storing "big data" such as a DataTable. Because the cookie has not only the 4k limit, and is not "purely stored in the client" is so simple, to know that the value of the cookie in each Web page request round trip is to be included in the HTTP header, if too much to occupy the network bandwidth between the server and the client (although only 4k, but the number of people online can be 4k * n). For the application of B/s structure, network bandwidth is one of the main bottlenecks of performance. In addition, the server CPU is consumed by converting datatbale into JSON strings and then storing cookies. The scariest thing is that once your cookie has been deleted, it's tragic that the user will be carrying this 4K size HTTP header in its expiration date and scope, when users access all of your pages. 10000 people online, 4,000 gigabit network card is not enough for you to spend.

3, the database connection, every time you save the query statement and then query the way good, but look at your query complexity, if the very time-consuming query, so call is not advisable. Memory and CPU contradiction you have to make a choice based on the actual situation. For applications with connection pooling, the cost of a single connection is not high, and is tested almost = 10 times the current system time function is called. However, the complexity of the query statement is flaky. In addition, if a large number of concurrent cases, the frequent use of database connections, will cause the connection pool is not available connections, it is tragic. At this time is not the cost of a connection, the overall performance of the system will be devastating decline, unresponsive.

4, Cache: a good choice, but it can also occupy the server memory Oh, just a little more flexibility than the session. But I also do not recommend that you use the place to store the pass parameters. To know that the session even if the memory is full will not lose your parameter value (will throw an exception), but the cache is not, it will directly delete your parameter values, even if the memory is extremely insufficient will not let you go in (and no error). In other words, perhaps the last line of code has just been saved, and the next line of code is lost. It's horrible.

5, Form form: The most advocated way, the HTTP protocol in the original page transfer value method is such, but sometimes not very convenient, can use it. 6, custom storage mechanism: If you are demanding performance requirements, or should not strive for excellence. Then write a storage mechanism yourself. For example, I wrote my own Xsession object, its usage is similar to session use, but the storage mechanism is my own encapsulation, both the advantages of the cache, but also the advantages of the session, as well as the advantages of the database, performance see you write algorithms, and have greater use of flexibility. The disadvantage is that you need your own coding ...

About the use of Cookie,session,cache in cache