Performance Optimization for Asp. Net websites-data caching

You have seen many articles about Asp. Net cache. So I need to change my mind when writing, starting from buffering and writing data. Data buffering means that data is not saved to the database immediately when the data needs to be updated. Instead, the data is buffered and then written to the database at the appropriate time.

Buffering and writing data can avoid the situation where the database is under too much pressure in an instant when there are too many concurrent accesses to the website, resulting in a deadlock or untimely response.

So when is it suitable for buffering? Is it applicable in all situations? Buffer writing may cause data to reside in the memory, on the web server hard disk, or in a third-party storage for a period of time. During this period, if you query the latest data from the database, there will be omissions. Most things have two sides, so we need to learn to seek benefits and avoid harm. In other words, when the buffer write does not make users feel that data is missing, alternatively, you can use a buffer to write data when appropriate measures are taken to prevent users from feeling that data is missing. I have two examples to illustrate how to use buffer write:

1. Pv (page views) statistics. Most websites have this function. Some websites also specialize in this service.
When a website is browsed, Pv + 1 is required for the corresponding page. In this case, if the page is directly updated to the database, A slight increase in access volume may cause a high database pressure problem.

So we need to buffer the Pv count. In the case of a single web server, we can maintain a hashtable in the memory, and then use an asynchronous thread to regularly scan this hashtable, when the number of clicks reaches a certain number, it is updated to the database. It sounds simple, but it also requires a little skill. The words "a certain number" in the previous sentence cannot be a random number. If it is 4, imagine what will happen, all of our PVS will be multiples of 4, and users will doubt if we are fake on Pv; we are not fake, but there are signs of fake! This "Number" must be a prime number. We can use 7 or 13. If we have a large access volume, we can use 23 or 31; in this way, there will be no signs of fraud.

2. Short Messages in the sending site
Intra-site short messages are also common modules. They can be said to be offline Messages rather than im instant messages. Therefore, we can use this service feature to buffer messages. When a short message is sent, we can first put the short message in the hard disk file, and then quickly respond to the user and tell the user on the ui that your message has been sent, then we can use another thread (or a windows Service) to monitor the directory sequence of buffered short messages and store the short messages in the database.

The above two scenarios are classic examples of using buffer write. In reality, we need to analyze whether the business and a business will cause database pressure to determine whether to buffer write, if the business itself has little pressure on the database, then of course there is no need to consider it. Otherwise, if the business pressure is high, we need to do some work to avoid the problem of buffer writing and use buffer writing.

Please respect the work of the author, repost please keep the link to yukai technical blog