Model-Oriented Software Architecture 3-resource management model Reading Notes (10)-Evictor Model

4.2 Evictor Mode

The Evictor mode describes when and how to release resources to optimize resource management. This mode allows us to configure different policies to automatically determine which resources should be released and when they should be released.

 

1. Problem

Highly robust and scalable systems must efficiently manage resources. Over time, ApplicationsProgramIt will get a lot of resources, some of which have only been used once. If the application continuously acquires resources without releasing them, it will lead to performance degradation and system instability. To avoid such a situation, the application can immediately release the resource after using the resource. However, applications may need to re-use the same resources, which requires re-obtaining those resources. Re-acquisition of resources may be costly, so we should avoid this by retaining frequently used resources in the memory.

To address these conflicting resource management needs, we need to pay attention to the following points:

1) optimality ). The frequency of resource usage should affect the resource lifecycle.

2) configurability ). Resource release should be determined by parameters such as resource type, available memory and CPU load.

3) Transparency ). The solution should be transparent to resource users.

 

2. Solution

Monitors the use of resources and uses a certain policy, such as least recently used (LRU) or least frequently used (LFU) to control its lifecycle. Each time a resource is used, it is marked by an application. When resources are not used recently or are not frequently used, they are not marked. Periodically, or, as needed, the application selects untagged resources and releases or clears them. The marked resources remain in the memory because they are frequently used.

In addition, other policies can be used to determine which resources should be cleared. For example, for applications with limited memory, you can use the size of resources to determine which resources should be cleared. Under such circumstances, resources that consume a large amount of memory may be cleared, even if it has been frequently used.

 

3. Structure

Resource users use resources, which can include applications or operating systems.

A resource is an entity, such as a service that provides certain types of functions.

Evictor clears resources based on one or more clearing policies.

Eviction strategy describes the criteria used to determine whether resources should be cleared.

 

 

4. Implementation

1) define the clearing interface. Define an interface to clear resources that can be cleared.

2) determine the resources that can be cleared. Developers must determine which resources can and should be cleared. For example, resources that are always required by applications, or resources that cannot be retrieved again should not be cleared. Any resources that can be cleared must be cleared. Before clearing resources, the application should call this interface to give the resources a chance to "handle" the problem, which includes persistence of any necessary status.

3) Decide to clear the policy. Based on application requirements, you can use different clearing policies to determine whether to clear resources and which resources can be cleared. Some policies used to determine which resources to clear include least recently used (LRU) and least frequently used (LFU ).

In addition, you can use custom policies that accept different parameters. For example, clearing a policy can consider how expensive it is to retrieve cleared resources. With such a policy, resources with a low re-acquisition cost may be cleared, even if they are used more frequently than the more expensive resources obtained.

4) define the use of cleanup in the system. The Service Logic for clearing resources needs to be added to the Evictor. This includes determining when and how resources should be cleared, and implementing marking the resources to be cleared. Generally, an Evictor exists as a separate object or component in an application and is configured by the application with the necessary clearing policy. For example, an application may choose to clear resources when the available memory is lower than a specific value. Another different application may implement more active policies and periodically clear policy resources, even if the memory is not lower than a certain value.

 

5. Conclusion

Advantages:

1) scalability ). The Evictor mode allows the application to retain an upper limit on the number of resources used, so that the application is in the memory at any given time, so that the application can be scaled without affecting the overall memory consumption.

2) low memory usage (low memory foorprint ). The Evictor mode allows applications to use configurable policies to control which resources should be kept in the memory and which resources should be released. By retaining only the most critical resources in the memory, the application can be "slim" and efficient.

3) Transparency ). The Evictor mode is used to make the resource release completely transparent to the resource users.

4) stability ). The Evictor mode reduces the possibility of resource depletion and increases application stability.

 

Disadvantages:

1) additional overhead ). The Evictor mode requires additional business logic to determine which resources are to be cleared and implement clearing policies. In addition, clearing resources may lead to significant execution overhead.

2) re-obtain the loss (re-acquisition penalty ). If you need to use the cleared resource again, you need to obtain the resource again. This may be costly and may affect the application performance. You can adjust Evictor to determine which resources are cleared to avoid this situation.