Using buffering technology to improve the performance and stability of JSP application

js| Performance

I. Overview

In Web applications, the generation of some reports may take a long time to compute, and some sites provide weather information that requires access to remote servers for SOAP calls to get temperature information. All of these are examples of complex information. Adding too much complex information to a Web page can cause the Web server, the database server, to overload. JSP code block buffering gives developers the freedom to arbitrarily increase the complexity of information.

JSP is able to encapsulate and run complex Java code in a tag library, making JSP page files easier to maintain, making it easier for non-professional developers to use JSP paging files. There are already many tag libraries that are either commercial or open source. But most of these products are only implemented in the form of tag libraries that can be implemented with a simple Java scriptlet, and few products use custom tags in a creative way, providing a usage that is almost impossible to implement before the JSP custom tag library appears.

The Oscache tag library, designed by Opensymphony, is a groundbreaking JSP custom tag application that provides the ability to implement fast memory buffering within existing JSP pages. Although there are already some vendors providing various forms of caching products, they all belong to a specific vendor-oriented product. Oscache can be run on any JSP 1.1-compliant server, not only to buffer existing JSP blocks for all users, but also to buffer them in user units. Oscache also includes advanced features that improve scalability, such as buffering to disk, programmable buffer refreshes, exception control, and more. In addition, as with Opensymphony's other products, Oscache's code is distributed free of charge under an open source license agreement.

This paper takes an imaginary auction website design process as an example to introduce the working process of Oscache. This hypothetical web site will include: a management page that reports on recent auctions, a full-featured home page with various promotional messages, and a special navigation bar that contains information about all the auctions that have not yet been sold by the user.

second, the management page

The auction site contains a management report that takes a few seconds for the database server to create such a report. Long report generation This is important because we may have multiple administrators monitor the system's performance while trying to avoid rebuilding the report every time the administrator accesses it. To do this, we will encapsulate the entire page within an application-level buffer, which is refreshed every 1 hours. Some of the products offered by other vendors also have similar functionality, but Oscache do better than they do.

For simplicity, we will not be overly concerned with formatting issues. When writing the admin page, we first add the tag Library declaration to the page:

<%@ taglib uri= "Cachetags" prefix= "Cache"%>

Next we'll use the cache tag to surround the entire page. The default buffer time for cache marks is 1 hours.

<cache:cache> ..... Complex management report .... </cache:cache>

Now the admin page has been buffered. If the administrator accesses the same page again within one hours after the page is generated, he will see a previously cached page that does not require the database server to generate the report again.

Third, homepage

The home page of the auction site shows the activity of the site, promoting those auctions that are coming to an end. We want to show the number of ongoing auctions, the number of current logged-in users, the list of auctions that will close in the short term, and the current time. This information has different time accuracy requirements. The auction on the site usually lasts a few days, so we can set the amount of time that is available to buffer the active auction to 6 hours. The number of users is obviously a bit more frequent, but we're going to buffer this value for 15 minutes at a time. Finally, we want the current time displayed in the page to always be the exact page access time.

After declaring the tag library on the home page, we first output the current date in a way that is not buffered:

Now: <%=new java.util.Date ()%>

Next, we'll show you a list of auctions that will end in a short period of time:

<cache:cache> <ul> <%//construct a iterator iterator auctions = ... while (Auctions.hasmore ()) {Auctio N Auction = (auction) auctions.next (); %><li><%=auction%></li%<}%> </ul> </cache:cache>

Finally, we want to show the number of ongoing auctions, which need to be buffered for 6 hours. Because the cache tag needs the number of seconds to buffer the data, we convert the 6 hours to 21,600 seconds:

<cache:cache time= "21600" > <%//Query database Gets the total number of auctions int auctioncount = ...%> This website is being carried out at auction with <%=auctioncount% > A! </cache>

As you can see, we built a home page with a complex buffering system with only a small amount of code. The buffer system buffers each part of the page, and the buffer time of each part is in full compliance with the frequency of their respective information changes. With buffering, we can now put more content into the home page, and in the absence of buffering, too much content in the home page can slow down page access and even overload the database server.

four, navigation bar

Suppose when planning a website, we decide to display the cart content below the left navigation bar. We will show you the number of bids and current quotes for each item that the user is auctioning, as well as a list of all the items that the current user has the highest bid for.

We use the session-level buffering 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 in the site reference the navigation bar:

<cache:cache key= "NavBar" scope= "session" Time= "> <%"//extract and display current bid information%> </cache:cache>

Here we introduce two important attributes, key and scope. In the code earlier in this article, because the cache tag can automatically create a unique key for a block of code, we do not need to manually set this key property. But here, we want to refer to this buffered block of code from the rest of the site, so we explicitly define the key property of the cache tag. Second, the scope attribute is used to tell the cache mark that the current code block must be buffered by the user, rather than buffering it once for all users.

You should be careful when using session-level buffering, and it should be clear that while we can reduce the complexity of the navigation bar by 5 times or 10 times times the server load, it will greatly increase the memory space required for each session. Increasing the number of possible concurrent users in terms of CPU capacity is certainly ideal, but once the number of concurrent users has been reduced to CPU limits in memory support capabilities, this scenario is no longer ideal.

As mentioned earlier in this article, we want to refer to this buffered block of code from the rest of the site. This is because, when a user adds a product for auction, or bids for another user's auction, we want to refresh the buffer so that the navigation bar next time is read with the latest content. Although the data may be changed by other users ' activities, he may be very confused if the user has not changed his or her list after performing an action on the site.

The Oscache library provides flush markup to refresh the buffered content. We can add the following code to the page that handles the user action and may affect the area:

<cache:flush key= "NavBar" scope= "Session"/>

The NavBar buffer block is refreshed the next time the user accesses it.

So far, the construction of our sample site has been completed and can begin to run. Let's look at Oscache's ability to handle exceptions. Even if the buffered content has been invalidated, such as a Java exception in the buffer block, the Oscache tag library still allows us to display the content in a programmatic way. With this exception control feature, we can remove the connection between the database server and the Web server, and the site continues to run. The JSP 1.2 specification introduces the Trycatchfinally interface, which allows the tag itself to detect and handle Java exceptions. Therefore, tags can combine this exception handling code to make JSP pages simpler and more organized.

Opensymphony is planning to implement additional buffering mechanisms and a more manageable master system that will enable us to manage the RAM and disk space used for buffering. Once these features are available, we can further improve the response speed and reliability of the site.

"Closing" Oscache can help us build a richer, more high-performance Web site. With the help of the Oscache tag library, we can now use it to solve some of the problems that affect web site responsiveness, such as peak traffic, overloading of database servers, and so on.