Improving the performance and stability of JSP program with Buffering technology

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.

..... Complex management report ....

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:

<%//Constructs a iterator iterator auctions = ... while (Auctions.hasmore ()) {Auction Auction = (Au ction) Auctions.next (); %>
• <%=auction%>

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:

<%//query database Gets the total number of auctions int auctioncount = ...%> This website is in the auction activity that has <%=auctionCount%>!

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.