Best Practices
This section contains a set of best practices for making your application's fragments "edge cacheable" (that is, cacheable on the "edge" by the ESI processor in the WebSphere Web server plug-in).
Modify the MVC (Model-View-Controller) design practices to isolate work into individual fragments. For example, the Trade3 home page provides personalized account information for an individual user as well as generic market summary data. To efficiently edge cache this output, the page is broken into two fragments. The personalized data is in tradeHome.jsp which is cached for each individual user, whereas the market summary page is cached as a single instance and shared by all users. To take advantage of edge caching, the work to produce the data for each page must be done in the page itself verses in a single controller servlet which does all of the work.
Further fragment pages when necessary. For example, the Trade3 quotes page provides quotes for an arbitrary list of stocks entered by the user. The page provides an HTML table with each row containing the price and other information for an individual stock. To take advantage of edge caching, a single JSP fragment page is created for the rows in the Quote.jsp page. This new page, displayQuote.jsp, computes the current information for a given stock symbol. This allows all stocks to be individually cached at the edge. The ESI processor will assemble the page fragments corresponding to each individual stock row to create the full table.
Unlike the dynamic cache service which runs within the WebSphere appserver, the ESI processor does not have access to user HTTP session data to uniquely identify page fragments. The application must be designed such that page fragments can be uniquely identified using request parameters on the URL, HTTP form data or HTTP cookies in the request. In a JSP include, parameters should be included in the URL as query parameters instead of as JSP parameter tags, thus allowing the ESI processor visibility to these values as query parameters.
Consideration should be given as to how expensive a given fragment is to compute. Fragments which are expensive to compute provide the best candidates for edge caching and can provide significant performance benefits. The cache entry sizes for Dynamic Caching and the ESI processor should be large enough to accommodate these expensive fragments. Also, the priority (or the time-to-live value) of these fragments should be raised to ensure less expensive fragments are removed from the cache first.
Another important consideration for edge caching is the update rate of a page. Invalidation of cached fragments is a relatively expensive operation. Therefore, very dynamic fragments which are invalidated often may not benefit from caching, and may actually hurt performance. Most Web application pages, however, are quasi-static and thus can benefit greatly from Dynamic Caching and edge caching in WebSphere.
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.