High-performance ASP. NET Website Construction-Managed Resource Optimization

High-performance ASP. NET Site build series Article Directories

This chapter describes in detail how to solve the performance problems caused by memory problems.. NET kernel for analysis, and then provide a solution. At the same time, other articles in this series also strive to achieve: in-depth introduction.

This article paves the way for the future and is more brilliant. Only by truly understanding this article can we proceed smoothly.

The topics in this article are as follows:

Memory problem Overview (previous)

Previous Article on managed resource optimization)

Object lifecycle before)

(Previous)

Large Object heap (LOH)

Previous Article on using CLR counters)

Optimization of unmanaged Resources

Session Optimization

Memory problems

Like CPU, memory is also an important hardware resource that directly affects server performance.

Generally, if the server memory is insufficient, the following two problems may occur:

1. As a result, the server writes some data originally written to the memory to the hard disk. This not only increases the CPU and disk I/O operations, but also prolongs the time for reading the data.

2. Some cache policies are blocked.

If the memory is insufficient, the fastest and most direct way is to buy a memory stick and add it to the server. However, there is a hidden problem: if the server is faced with insufficient memory after a new memory is added, it is impossible for us to add memory in an endless manner, then we must solve this problem from the site itself, such as configuring the server, analyzing and optimizing the site code.

Managed Resource Optimization

I believe you are no stranger to hosting resources. Simply put, the resources created on the hosting heap of C #, or the objects generated through new, are the same.

Before giving an in-depth explanation, let's take a look at the object lifecycle"

Object Lifecycle

When we create an object with the new Keyword, this object is allocated to the CRL hosting heap. The managed heap is in the memory. In addition, the object space allocation speed is very fast, because each time a certain amount of space is drawn at the end of the hosting heap to give this object, you do not need to find a suitable size on the heap.

If the managed heap prepares to allocate space for an object and finds that the space on the managed heap is too small to be allocated to the new object, the CLR starts to run the garbage collection mechanism. We know that the garbage collection mechanism will clear all the objects without reference pointing to on the managed heap, and compress the existing objects on the managed heap.

However, it should be clear that some useless objects are cleared during garbage collection, but only when the next garbage collection is performed, the objects that were cleared in the previous garbage collection were actually eliminated from the memory (at this time, there are some "Object recovery" topics that will not be described in detail ).

The following describes some garbage collection topics.

Object generation"

During CLR garbage collection, the garbage collector goes back to the managed heap to check whether the object can be recycled. This check process consumes a lot of resources. In order to avoid convenient hosting of all objects on the stack for each garbage collection, CLR divides the objects on the managed stack by "Generation", for example, the first generation and the second generation. Then, every time you scan the managed heap conveniently, scan the objects in a "Generation" to improve the performance.

In the managed heap, objects can be divided into three "generations": 0 generation, 1 generation, 2 generation, only these three generations. Each object starts from generation 0. Every time an object experiences garbage collection, and this object is still in use, the "Generation" of this object will be increased by 1 generation. For example, if a zero-generation object experiences garbage collection, its generation is the first generation. If it is a one-generation object, it will eventually become the second generation. If the object itself is two generations, no matter how many garbage collection times (if the object has been in use), then this object is still two generations.

In CLR garbage collection, remember: "The larger the number of 'data', the less likely it will be to be recycled ". And some performance optimization is based on this.

Every time the CLR recycles garbage, it will first scan 0th generations of objects. Therefore, some new temporary objects can be immediately cleared. In contrast, the garbage collector does not scan 1st generations of objects more frequently than 0th generations, and the frequency of scanning 2nd generations of objects is lower. Therefore, the longer the object remains, the more difficult it will be to be recycled and it will occupy the CLR memory resources.

It should also be noted that, if the CLR decides to scan the 1st generation object, it also uses scanning the 0th generation object, and if the CLR scans the 2nd generation object, The 0th generation object, all 1st generation objects will be scanned.

Therefore, we can conclude from this that we try to avoid turning the objects that need to be recycled immediately into objects that will survive for a long time. In layman's terms, if an object already exists in the 0 generation and is recycled after it is used up, we should not keep it in the 1st generation or even 2nd generation. In programming, this is basically the implementation idea: instantiate objects as late as possible, and release objects as early as possible.

Large Object Heap (Large Objecet Heap)

We previously talked about some topics of "heap". Apart from the general heap above (the heap where the new object allocates space), there is another heap in CLR: it is used to place heaps and large object heaps of objects larger than 85kb.

If the size of the new object exceeds 85 KB, the CLR will put the object on the LOH. If the LOH space is insufficient at this time, the CLR will start the Garbage Collector to scan the LOH heap and the 2nd generation object on the general heap. We have said that if we scan the 2nd generation object, scanning the 1st and 0th generations at the same time is equivalent to scanning the entire managed heap, and the performance impact can be imagined.

And don't want the previous normal heap. After the objects on the LOH are recycled by the garbage collector, the large objects on the LOH won't be compressed, there may be some "Space fragments" on the LOH heap. When allocating new large objects, we need to find space and even sort the fragments, you can think of the disk fragmentation of our computer.