InfoCenter Home >
4: Developing applications >
4.5: Dynamic fragment cache >
4.5.2:   External caching

4.5.2:   External caching

WebSphere Application Server's dynamic cache has the ability to control external caches on Web servers, such as IBM Edge Server and IBM HTTP Server. When external caching is enabled, the cache matches pages with their URIs and pushes matching pages to the external cache. The entries can then be served from the external cache instead of the application server. This creates a significant savings in performance.

Only certain fragments are eligible for external caching. Since the external cache must use the full URI as a cache id, the servlet being externally cached uses that URI as its internal cache id as well. Also, because the the cache automatically uses the URI to build cache ids, it is illegal to define cache variables (for example, request, session, and cookie variables) in an externally cacheable servlet.

Only full pages are pushed out to external caches, so only externally accessible servlets should be defined as externally cacheable. For example, if page1.jsp includes page2.jsp and page3.jsp, then only page1.jsp should be declared externally cacheable. If page3.jsp is invalidated, then the cache also invalidates the external entry for page1.jsp. Therefore the next request for page1.jsp is sent to WebSphere Application Server.

Servlet and JSP file content that is private, requires authentication, or uses SSL should not be cached externally. The authentication required for those servlet or JSP file fragments cannot be performed on the edge. A suitable timeout value should be specified if the content is likely to become stale.

Enabling external caching of servlets and JSP files with IBM Edge Server

Edge Server users should consult the Edge Server documentation for information on configuring external caching between WebSphere Application Server and Edge Server.

Enabling high speed caching of Servlets and JSP files with IBM HTTP Server for Windows NT/2000

IBM HTTP Server for Windows NT/2000 contains a high speed cache referred to as the Fast Response Cache Accelerator, or Cache Accelerator. WebSphere Application Server's fragment cache can use IBM HTTP Server as an external cache with appropriate configuration.

After installing WebSphere Application Server and IBM HTTP Server for Windows NT, you must do the following to enable the Cache Accelerator:

  1. Configure caching on the Web server.

    In the IBM HTTP Server conf directory, locate the httpd.conf configuration file, and add the following two lines at the end of the file:

    LoadModule afpaplugin_module c:/WebSphere/AppServer/bin/afpaplugin.dll
    AfpaPluginHost 127.0.0.1:9081

    The first line loads the IBM HTTP Server plug-in that connects the Cache Accelerator to WebSphere's fragment cache. Ensure the LoadModule path points to your Websphere Application Server installation.

    The second line defines the application server instances that should be connected to this module. When multiple instances of WebSphere Application Server are defined, repeat the second line for each application server. If the instances are on different machines from the Web server, use the instances' IP address instead of the localhost address defined in this example. In the case of multiple application servers on the same host, choose a different port number for each instance.

  2. Configure an external cache group on the application server.

    For each application server that uses the Cache Accelerator, define an external cache group named afpa. Add a member to that group with an adapter bean name of com.ibm.servlet.dynacache.Afpa. For the address, enter the assigned port number from the Web server's httpd.conf file. An example of this configuration is available in the dyncache.sample.xml file located at:
    product_installation/properties/dynacache.sample.xml
    See the global configuration section in this file for more information.

  3. Configure a cache policy using external cache.

    Now you can use the external cache attribute when building your cache policies. See article Policy configuration for information on building cache policies.

You can test your configuration by doing the following:

  1. Do a CD (change directory) to the product_installation/properties directory.
  2. Copy the servletcache.sample.xml file to servletcache.xml.
  3. Update the first entry with the following definitions to enable the external high speed cache:
    <servlet>
         <timeout seconds="0" />
         <servletimpl class="SnoopServlet.class" />
         <externalcache id="afpa" />
    </servlet>
  4. You can test your changes using the SnoopServlet sample for external caching. The SnoopServlet.class is located in:

    product_installation\installedApps\sampleApp.ear\default_app.war\WEB-INF\classes

    The first request for http://yourhost/servlet/SnoopServlet results in the response being loaded in the high speed cache. Subsequent requests are served directly from the cache, which significantly enhances performance.

    Setting the "timeout seconds" to "0" means the cached entry remains permanently cached. Setting it to a positive non-zero value, as for example, 30, causes the high speed cache entry to be deleted after the specified number of seconds, in this case 30.

    To enable JSP files for caching, add the following stanza to the servletcache.xml file:

    <servlet>
         <timeout seconds="10" />
         <path uri="/very_simple.jsp" />
         <externalcache id="afpa" />
    </servlet>

    In this example, you cache the response for 10 seconds when the http://yourhost/very_simple.jsp file is requested. The file, very_simple.jsp is located in:

    product_installation\installedApps\sampleApp.ear\default_app.war
    

    After 10 seconds, the cache entry is deleted. The cache entry is updated when a new request occurs for the JSP file.

      The IBM HTTP Server Fast Response Cache Accelerator is available on both Windows NT/2000 and AIX. However, dynamic caching support is currently only available on Windows NT/2000.

Configuring the Fast Response Cache Accelerator cache size.

In the default IBM HTTP Server configuration, the maximum Cache Accelerator dynamic cache size is calculated as 1/8 of physical (pin-able) memory. On a machine with 384Meg of RAM, it allows a maximum of approximately 50Meg for the Cache Accelerator dynamic cache. When this limit is reached, the Cache Accelerator then deletes older entries to cache new ones.

The IBM HTTP Server directive, AfpaDynaCacheMax, can be used to fine tune the maximum allowed cache size. This directive must be placed in the global server configuration scope (along with the other default Cache Accelerator directives), and Cache Accelerator must be enabled.

Update the following directives in the httpd.conf file of IBM HTTP Server :

AfpaEnable
AfpaCache on
AfpaLogFile "c:/Program Files/IBM HTTP Server/logs/afpalog" V-ECLF
AfpaDynaCacheMax 10

The above settings enable the Cache Accelerator and limit the dynamic cache size to 10 Meg. If you use these directive to increase the cache size, do not make the cache so large that all physical memory is consumed. You can determine how much memory is available, when all the applications are running, by using the Windows Task Manager.

Assign no more than 50% of available physical memory to the dynamic cache. Specifying too large a cache not only decreases the performance of other applications, but also puts you at risk for completely running out of memory.

The default configuration does not include the AfpaDynaCacheMax directive where the cache size is automatically calculated as 1/8 of physical memory.

Go to previous article: Custom ID and MetaData generators Go to next article: Dynamic fragment cache frequently asked questions

 

 
Go to previous article: Custom ID and MetaData generators Go to next article: Dynamic fragment cache frequently asked questions