I. Overview
In Web applications, the generation of some reports may take a long time for the database to calculate. Some websites provide weather information, which requires access to a remote server for SOAP calls to obtain temperature information. All of these are examples of complex information. Adding too much complex information to the Web page may cause excessive load on the Web server and database server. The buffer of JSP code blocks gives developers the freedom to add various complex information at will.
JSP can encapsulate and run complex Java code in the tag library, making it easier to maintain JSP page files, making it easier for non-professional developers to use JSP page files. There are already many tag libraries, either commercial products or open source code products. However, most of these products only use the tag library to implement functions that can be implemented with a simple Java Scriptlet. Few products use custom tags in a creative way, it provides usage that is almost impossible to implement before the JSP custom tag library appears.
The OSCache tag library is designed by OpenSymphony. It is a groundbreaking JSP custom tag application that provides fast memory buffering within the existing JSP pages. Although some vendors are already providing various types of cache products, they all belong to specific vendors. OSCache can run on any JSP 1.1 compatible server. It can not only buffer existing JSP code blocks for all users, but also buffer them by users. OSCache also includes some advanced features to improve scalability, such as buffering to disks, programmable buffer refreshing, exception control, and so on. In addition, like other OpenSymphony products, OSCache code is also released free of charge under an open source code license agreement.
This article takes the design process of a hypothetical auction website as an example to introduce the working process of OSCache. This hypothetical Web site will include: a management page for reporting recent auction events; a fully functional home page with various promotional information; A special navigation bar, it contains information about all the unsold auction activities of the user.
Ii. Management page
The auction website contains a management report. It takes several seconds for the database server to create such a report. It is important to generate a report for a long time, because we may allow multiple administrators to monitor system running conditions and avoid the administrator from generating the report every time he accesses the report. To achieve this, we encapsulate the entire page into an application-level buffer tag, which is refreshed every hour. Some products provided by other vendors also have similar features, but OSCache is better than them.
For the sake of simplicity, we will not focus much on the format issue. When writing the management page, we first add the tag library declaration to the page:
<% @ Taglib uri = "cachetags" prefix = "cache" %>
Next we will use the cache tag to enclose the entire page. The default cache duration is one hour.
<Cache: cache>... complex management reports... </cache: cache>
The management page is buffered. If the Administrator accesses the same page again within one hour after the page is generated, he will see the previously cached page, and the database server does not need to generate this report again.
3. Home Page
The home page of the auction website displays the activity information of the website and promotes the upcoming auction activities. We want to display the number of ongoing auction activities, the number of currently logged-on users, the list of auction activities that will end in the short term, and the current time. This information has different time precision requirements. The auction activity on the website usually lasts for several days, so we can set the buffer effective auction activity quantity to 6 hours. The number of users is obviously changing frequently, but here we will buffer this value for 15 minutes each time. Finally, we hope that the current time displayed on the page will always be the exact page access time.
There are two pages in this news. Currently, there are two pages in page 1st.
After declaring the tag library on the homepage, we first output the current date directly without buffering:
Now:
<% = New java. util. Date () %>
Next, we will display a list of auction activities that will end in the short term:
<Cache: cache> <ul> <% // construct an Iterator auctions = .... while (auctions. hasMore () {Auction auction = (Auction) auctions. next (); %> <li> <% = auction %> </li % <}%> </ul> </cache: cache>
Finally, we want to display the number of ongoing auction activities. This number needs to be buffered for 6 hours. Because the cache tag requires the number of seconds to buffer data, we convert 6 hours to 21600 seconds:
<Cache: cache time = "21600"> <% // query the database to obtain the total number of au events int auctionCount = .... %> There are <% = auctionCount %> ongoing au events on this website! </Cache>
We can see that we only use a small amount of code to construct a home page with a complex buffer system. This buffer system caches each part of the page separately, and the buffer time of each part fully complies with the frequent changes of their respective information. With buffering, we can add more content to the home page. If there is no Buffering in the past, too much content on the home page will lead to slow page access, it may even overload the database server.
Iv. navigation bar
When planning a website, we decided to display the content of the shopping cart at the bottom of the navigation bar on the left. We will display the number of bids and current prices for each item auctioned by the user, as well as the list of all the items with the highest bid by the current user.
We use the session-level buffer capability to construct the above functions in the navigation bar. Put the following code into a template or include a file so that other pages on the website can reference this navigation bar:
<Cache: cache key = "navbar" scope = "session" time = "300"> <% // extract and display the current bid information %> </cache: cache>
Here we introduce two important attributes: key and scope. In the code above this article, because the cache tag can automatically create a unique key for the code block, we do not need to manually set this key attribute. But here, we want to reference this buffered code block from the rest of the website, so we explicitly define the key attribute of the cache tag. Second, the scope attribute is used to indicate that the current code block must be buffered by the user, rather than all users.
When using session-level buffering, you should be very careful: although we can reduce the server load of complicated navigation bars by 5 or 10 times, but it will greatly increase the memory space required by each session. It is undoubtedly ideal to increase the number of concurrent users in terms of CPU capabilities. However, this solution is no longer ideal once the number of concurrent users is reduced to the limit of CPU in terms of memory support capabilities.
As mentioned above, we want to reference this buffer code block from the rest of the website. This is because when a user adds a product for the auction, or bid for the product auctioned by another user, we want to refresh the buffer, this gives the navigation bar the latest content when it is read next time. Although the data may be changed due to activities of other users, the user may be very confused if the user sees that his/her list has not changed after performing an action on the website.
The flush flag provided by the OSCache library can refresh the buffered content. We can add the following code to the page that handles user actions and may affect this area:
<Cache: flush key = "navbar" scope = "session"/>
When you access it next time, the navbar buffer is refreshed.
So far, the construction of the sample website has been completed and can be started. Next, let's take a look at the OSCache exception handling capabilities. Even if the buffered content has been voided, for example, a Java exception occurs in the buffer block, the OSCache tag library still allows us to display the content programmatically. With this exception control function, we can remove the connection between the database server and the Web server, and the website can continue to run. The TryCatchFinally interface is introduced in the JSP 1.2 specification, which allows the mark itself to detect and handle Java exceptions. Therefore, the tag can be combined with this exception processing code to make the JSP page simpler and more organized.
OpenSymphony is planning to implement other caching mechanisms and a master system with better manageability. It will enable us to manage the RAM and disk space used for caching. Once these functions are available, we can further improve the website's response speed and reliability.
[Conclusion]
OSCache can help us build more colorful and high-performance websites. With the help of the OSCache tag library, we can use it to solve problems that affect website response capabilities, such as peak traffic volumes and heavy load on database servers.
There are two pages in this news. Currently, there are two pages in page 2nd.
