Use of ehcache page Cache

 

There have been many discussions about cache in the forum. Simply put, if 80% of the data is accessed by an application within 20% of the time, cache should be used at this time. This is in conflict with the long tail theory. In fact, it is not in conflict. It is just that different theories use different scenarios. Where the 80/20 principle takes effect, we should all consider whether the cache can be used. However, caching has different usage. For example, the homepage of a website is estimated to be accessed the most frequently. We can consider caching a page for the homepage, if only the first few pages in the Java version of javaeye are accessed most frequently on a page (assuming that javaeye uses hibernate, of course, this is just an assumption, we all know that javaeye is developed using ror.) Then we can consider providing a second-level cache for the record in the Java edition, because the second-level cache is saved Based on the Object ID, so it should be said that the objects used in the previous pages will always exist in the cache (how to use the hibernate second-level cache jar is also introduced ). It can be seen that the cache policies for different pages may be quite different.

The purpose of this article is to cache pages in one of the two cases mentioned above. There is no doubt that almost all websites have the highest homepage coverage rate, and the data sources on the homepage are very extensive. Most of them come from different objects and may come from different databases, therefore, it is a good idea to cache the homepage. What does the homepage cache policy look like? I think it should remain the same for a fixed period of time, for example, it should be updated every 2 minutes. So where should the cache be implemented? Let's take a look. Suppose your application structure is page-filter-action-service-Dao-DB, in this process, the cache can be cached. According to the page cache features, the page cache should be as close as possible to the customer, that is, between the page and the filter, this advantage is that after the first user request, the page is cached, and when the second user requests again, the request ends when it reaches the filter, you do not need to follow the action-service-Dao-DB. The benefits are reduced server pressure and accelerated response to customer segments.

Let's take a look at how to use ehcache to achieve this.

Before using the ehcache page cache, we must understand several concepts of ehcache,

1 timetoidleseconds. If you do not access the cache for a long time, the ehcache will clear the cache.

2 timetoliveseconds: indicates the cache survival time, which is counted from the start time.

Here, we know that the survival time of the page cache on the homepage is set to 2 minutes, so our timetoliveseconds should be set to 120, at the same time, we recommend that you set timetoidleseconds to 2 minutes or less. Let's take a look at the configuration below the plugin. This configuration segment should be put in ehcache. xml:

<Cache name = "simplepagecachingfilter"

Maxelementsinmemory = "10"

Maxelementsondisk = "10"

Eternal = "false"

Overflowtodisk = "true"

Diskspoolbuffersizemb = "20"

Timetoidleseconds = "10"

Timetoliveseconds = "10"

Memorystoreevictionpolicy = "LFU"

/>

Simplepagecachingfilter is the cache name. maxelementsinmemory indicates that the maximum number of elements in the cache of simplepagecachingfilter in the memory is 10, and maxelementsondisk indicates that the maximum number of elements that are cached to the hard disk is 10 (), eternal = false means that the cache will die. Overflowtodisk = true indicates that when the number of elements in the cache exceeds the limit, these elements are persisted to the hard disk. If overflowtodisk is false, the setting of maxelementsondisk is meaningless. Memorystoreevictionpolicy = LFU indicates to clear the cache according to the cached hit value. That is to say, when the cache is full, the new object needs to be cached, and the objects with the smallest hit value in the cache will be cleared out of the cache, make room for new objects (this article introduces three cache clearing policies in ehcache ).

Next, let's take a look at the configuration of simplepagecachingfilter,

<Filter>

<Filter-Name> indexcachefilter filter-Name>

<Filter-class>

Net. SF. ehcache. constructs. Web. Filter. simplepagecachingfilter

Filter-class>

Filter>

<Filter-mapping>

<Filter-Name> indexcachefilter filter-Name>

<URL-pattern> * index. Action URL-pattern>

Filter-mapping>

You only need to perform these steps to cache a page and put the above configuration in your web. in XML, when you open the homepage, you will find that there will be a bunch of SQL statements in the console within 2 minutes. Of course, you can change it to 5 minutes. Everything is under control.

Well, it looks very simple to cache the entire page. You don't even need to write a line of code. Just a few lines of configuration are required. It's simple enough, although it looks simple, but in fact, the internal implementation is not simple. If you are interested, you can look at the source code of the simplepagecachingfilter inheritance system.

The above configuration applies to the cache of all the home pages. If you only want to cache part of the content of the home page, you need to use the filter simplepagefragmentcachingfilter. Let's take a look at the following parts:

<Filter>

<Filter-Name> indexcachefilter filter-Name>

<Filter-class>

Net. SF. ehcache. constructs. Web. Filter. simplepagefragmentcachingfilter

Filter-class>

Filter>

<Filter-mapping>

<Filter-Name> indexcachefilter filter-Name>

<URL-pattern> */index_right.jsp URL-pattern>

Filter-mapping>

This JSP needs to be added to other pages by JSP: Include, so as to cache local pages. This does not seem to be useful for Oscache tags.

In fact, another feature in cachefilter is gzip, which means that the cached elements are compressed. If the client browser supports compression, the filter will directly return the compressed stream, in this way, the bandwidth is reduced and the decompression work is handed over to the customer's browser. If the customer's browser does not support gzip, then, the filter will extract the cached elements and then return them to the client's browser (most crawlers do not support gzip, so the filter will decompress the filter before returning the content ), the advantage of doing so is to save bandwidth, but the disadvantage is to increase the burden on the client's browser (but I think this burden is minimal for contemporary computers ).

Well, if your page needs to use the page cache, consider ehcache because it is very simple and easy to use.

Conclusion: ehcache is a lightweight cache implementation that supports clusters SINCE 1.2. The latest version is 1.3 and is the default cache provider of hibernate. Although this article describes the support of ehcache for page caching, The ehcache function is far more than that. Of course, cache should be used well. For the principle and scope of use of cache in Jee, the applicable scenarios must be well understood so that the cache can be used properly and the cache can be used.

Finally, let's review the three clearing policies cached in ehcache:

1 FIFO, first in first out, this is the most familiar one, first in first out, not much to talk about

2 LFU and less frequently used are the strategies used in the above example. To put it bluntly, they are least used. As mentioned above, the cached element has an hit attribute, and the minimum hit value will be cleared out of the cache.

2 LRU, least recently used, least recently used. The cached element has a timestamp. When the cache capacity is full and you need to make room for caching new elements, the elements whose timestamp is the farthest from the current time in the existing cache will be cleared out of the cache.