Caching dynamically generated content

The dynamic caching function enables Caching Proxy to cache dynamically generated content in the form of responses from JavaServer Pages (JSP) and servlets that are generated by an IBM® WebSphere® Application Server.

This applies to reverse proxy configurations only.

A Caching Proxy adapter module is used at the application server to modify the responses so that they can be cached at the proxy server in addition to being cached in the application server's dynamic cache. With this feature, dynamically generated content can be cached on the edge of the network, freeing the content host from making repeated requests to the application server when more than one client requests the same content.

Note: The dynamic caching feature does not enable the proxy server to cache results from URL queries.

It is sometimes necessary to enable query caching in order for the dynamic caching feature to work, for example, if your servlets use URLs in the form of queries. The proxy server considers any URL that contains a question mark (?) to be a query.

The caching of dynamically generated content offers the following benefits:
  • It reduces the load on the content hosts.
  • It reduces the load on the application servers.
  • It speeds the delivery of requested resources to users.
  • It reduces bandwidth usage between servers.
  • It improves scalability for websites that create or serve dynamically generated content.

The application server exports only fully composed public pages for proxy caching. Private pages are not cached by the proxy. For example, a dynamically generated page from a public site that lists the current weather forecast can be exported by the IBM® WebSphere® Application Server and cached by Caching Proxy. However, a dynamically generated page that lists the contents of a user's shopping cart cannot be cached by the proxy server. Also, in order for a dynamically generated page to be cached, all subcomponents of that page also must be cacheable.

Cached dynamic files do not expire in the same way that regular files do; they can be invalidated by the application server that generated them. The invalidation process can be done directly or through the Content Distribution system.

Entries in the dynamic cache are invalidated in the following circumstances:
  • The dynamic cache garbage collector removes an entry because of cache congestion.
  • The timeout set in the servlet entry (servletcache.xml) or in the proxy's ExernalCacheManager directive expires.
  • An external agent or application invokes the dynamic cache APIs to invalidate cache entries. (Optionally, this task can be done by using the Content Distribution system to send invalidation messages.)
Invalidation of dynamic cache entries is always done by generating an Invalidate message for the specific instance of the Caching Proxy dynamic caching plug-in. Caching Proxy receives Invalidate messages as posts to the /WES_External_Adapter resource locator. Caching Proxy then clears the invalid entries from its cache.
Dynamic caching requires the following configuration steps.
  • IBM WebSphere Application Server configuration:
    • Configure each application server to do local dynamic caching.
    • Configure each application server to use the External Cache adapter.
    • Specify which external caches can be used for each cacheable servlet and JSP file.
    • Set advanced dynamic caching features for proxy caching by using the dynaedge-cfg.xml file. (This step is optional but suggested.)
  • Caching Proxy configuration:
    • Enable Caching Proxy to use the dynamic caching plug-in.
    • Specify the sources from which dynamic content is cached.

Configuring IBM WebSphere Application Server for proxy caching

Configure dynamic caching at the application server

Follow the instructions in the IBM WebSphere Application Server documentation for configuring your application server to use its local dynamic cache (also called the dynamic fragment cache). The dynamic fragment cache interacts with the external cache at the Application Server Caching Proxy.

Configure the application server adapter

The IBM WebSphere Application Server communicates with Caching Proxy by using a software module that is called the External Cache adapter, which is installed with the Application Server.

Note: Refer to the IBM WebSphere Application Server support website for a technote about configuring dynamic caching.

Configure advanced features

The dynaedge-cfg.xml file describes the characteristics of the external cache and enables interaction with the Content Distribution system . The file is installed on the Application Server in the path install_directory/edge/asate/conf/dynaedge-cfg.xml. Using this file is optional for a basic dynamic caching configuration, but the file is required to enable such features as security and authorization for invalidation requests, and to configure connection details. It also is required for use of the Content Distribution system.

Figure 1 shows the Document Type Definition (DTD) schema for the dynaedge-cfg.xml file:
Figure 1. The DTD for the dynaedge-cfg.xml configuration file
?xml version="1.0"?>
!DOCTYPE EdgeServerCfg [
    !ELEMENT EdgeServerCfg (EdgeServer* | MasterCDS* | ConnectionProperties?)>
    !ELEMENT EdgeServer EMPTY>
    !ATTLIST EdgeServer
        endpoint                  CDATA #REQUIRED
        user                      CDATA #IMPLIED
        userPasswd                CDATA #IMPLIED
        invalidation-url          CDATA #IMPLIED
        URI-type                  (relative | absolute) "absolute"
    >

    !ELEMENT MasterCDS EMPTY>
    !ATTLIST MasterCDS
        endpoint                  CDATA #REQUIRED
        domain-name               CDATA #IMPLIED
    >

    <!ELEMENT ConnectionProperties EMPTY>
    <!ATTLIST ConnectionProperties
        timeOut                   CDATA #REQUIRED
        certFile                  CDATA #IMPLIED
        certPasswd                CDATA #IMPLIED
        certFileType              CDATA #IMPLIED
    >

]>
In the preceding figure, an asterisk (*) indicates that there can be zero or more values for this item. A question mark (?) indicates that there can be zero values or one value for this item.
The following descriptions provide information on the DTD elements in the dynaedge-cfg.xml configuration file:
EdgeServer
This element describes the dynamic caching and invalidation aspects of Caching Proxy. The attributes for this element include the following:
endpoint
This attribute defines a unique protocol, IP address, and port to identify Caching Proxy that is to receive the invalidate requests.
Note: If an endpoint value is not unique, the first endpoint match that is encountered in the dynaedge-cfg.xml configuration file prevails over any duplicate entry. Similarly, the first endpoint match encountered in the dynaedge-cfg.xml configuration file prevails over any duplicate endpoint match that is specified in the dynacache.xml configuration file.
It is valid to specify no external caches. To specify no external caches, enter an empty set of quotation marks ("") as the value for the corresponding member address attribute in the dynacache.xml file. The member address attribute is contained in the entry that identifies the external caching groups (externalCacheGroups>) in the dynacache.xml file. For example, the following is a valid entry:
member address ="" \
adapterBeanName="com.ibm.websphere.edge.dynacache.WteAdapter">
This entry spans a single line in the dynacache.xml file.
user, userPasswd
This attribute identifies the user and specifies the password, which is defined at the proxy server by using the htadm command.

These attributes provide security for invalidation requests made to the proxy server cache. Currently, only basic authorization is supported. Use the HTTPS protocol to transport the invalidation requests.

invalidation-url
By including this attribute, the administrator can select the URL over which invalidation requests are to be received. You must include a corresponding Service entry to match this attribute in the Caching Proxy configuration file (ibmproxy.conf). If this attribute is omitted, the external cache adapter uses /WES_External_Adapter as the default value.
URI-type
This attribute identifies the URL format that is to be used for caching objects at the proxy server. The invalidate requests that are used for these cached objects must match this format. The value for this attribute can be either absolute or relative. The value of the URI-type attribute corresponds to the CacheByIncomingURL directive that is entered in the Caching Proxy configuration file (ibmproxy.conf). The correspondence is as follows:
  • When the value for the URI-type attribute is absolute, the corresponding CacheByIncomingURL directive in the ibmproxy.conf configuration file is CacheByIncomingURL off.
  • When the value for the URI-type attribute is relative, the corresponding CacheByIncomingURL directive in the ibmproxy.conf configuration file is CacheByIncomingURL on.

The decision to turn this directive on or off is made on a case-by-case basis for each proxy server. The default value for the directive is off; therefore, the default value of the URI-type attribute is absolute.

MasterCDS
This element identifies the root of the Content Distribution network to which invalidation requests are sent. If you do not want the Content Distribution system to be used for dynamic caching invalidations, do not specify values for these elements.
endpoint
This attribute supplies a unique protocol, IP address, and port to identify the master server in the Content Distribution network domain. The Content Distribution system currently supports only the HTTP protocol for sending invalidation notifications.
domain-name
This optional attribute can be used to supply the domain ID that identifies the Content Distribution network.
Additional configuration steps are necessary to create a Content Distribution network. Refer to the [Content Distribution Admininstration Guide] for complete information.
ConnectionProperties
This element sets values related to communication with Caching Proxy.
timeOut
This attribute sets the maximum time to wait for a response.
certFile, certPasswd, certFileType
When Caching Proxy uses Secure Sockets Layer (SSL) as the transport protocol for invalidation requests, these attributes identify and authenticate the custom certificate authority that can validate the server certificate.
Figure 2 shows an example entry in the dynaedge-cfg.xml configuration file. In the example, the external cache adapter is providing credentials to Caching Proxy, which authorizes an invalidate request for cached items. Note that quotation marks (" ") must be used with all values.
Figure 2. An example entry in the dynaedge-cfg.xml configuration file
EdgeServerCfg>

  EdgeServer
    endpoint = "http://serverName:80"
    user = "userid1" 
    userPasswd = "secret" 
    invalidation-url = "/WES_External_Adapter"
    URI-type = "absolute"
  />

  EdgeServer
    endpoint = "https://server2:443"
    user = "userid2" 
    userPasswd = "anothersecret" 
    invalidation-url = "/invalidate-dynamic-contents"
    URI-type = "absolute"
  />

  MasterCDS
    endpoint = "http://mcds_1:8005"
    domain-name =  "www.acme.com"
  />

  <ConnectionProperties 
    timeOut = "60"
    certFile = "/opt/WebSphere/AppServer/java/jre/lib/security/cacerts"
    certPassword = "changeit"
    certFileType = "JKS"
  />

/EdgeServerCfg>	

Deciding whether to use the Content Distribution system for cache invalidations

The dynamic caching feature in WebSphere Application Server, Version 8.5 can be used with or without using the Content Distribution system to send invalidation messages for cached dynamically generated content.

The Content Distribution system offers the following benefits and limitations when it is used for dynamic cache invalidations:
  • Improved scalability — If Content Distribution is used, application servers need to send only one content invalidation message to the master server, instead of sending messages to every proxy server that has cached their content.
  • Subscription capabilities — The Content Distribution system enables updates to Caching Proxy for additional, non-dynamic content by subscription.
  • More complicated set-up — Setting up a Content Distribution system to do cache invalidations requires more software installation and configuration than setting up direct invalidations.
  • Simplified administration — After it is set up, the Content Distribution notification system can be administered by an application server administrator who does not have extensive knowledge of Application Server, or vice versa.
  • Unencrypted invalidation messages — When the Content Distribution system is used, invalidation messages currently cannot be encrypted (sent using SSL) and cannot require authorization at the Application Server proxy. If direct invalidation is used, encryption and authorization are possible.

Consider the needs of your own installation when deciding whether to use the Content Distribution system for dynamic caching invalidations. For example, a Web site with multiple Application Server Caching Proxy nodes that reside in the same administrative domain as the application servers might not need to use secured invalidation messages and would benefit from the scalability and additional content distribution capabilities that the Content Distribution system provides. A Web site with proxy nodes in a different administrative domains might require security for the invalidation messages and simplified set-up at remote nodes; this system might use direct invalidations. It also is possible to configure your system to use both methods: in other words, some proxies can receive direct invalidations while others receive invalidations through the Content Distribution system.

Configuring Caching Proxy for dynamic caching

To enable the proxy server to cache dynamically generated content (results from servlets and JSPs), you must make two changes in the proxy configuration file, ibmproxy.conf. The first change enables the dynamic caching plug-in module, and the second change configures it to recognize the sources of cacheable dynamic content.

Set the Service directive to enable the dynamic caching plug-in

An API directive for the Service step is used to enable the dynamic caching plug-in. To create this directive, either manually edit the ibmproxy.conf file, or if the proxy server is already running, use the Configuration and Administration forms to select Server Configuration –> Request Processing –> API Request Processing. The content of the directive is shown in examples that appear later in this section.

A prototype Service directive for enabling dynamic caching exists as a comment in the API section of the ibmproxy.conf file. It has the heading JSP Plug-in. The prototype API directives are in a purposeful order. When adding API directives to enable new features and plug-in modules, order the directives as shown in the prototype section of the configuration file. Optionally, you can remove the comment characters from the prototype API directives and edit them as necessary to include support for each wanted function or plug-in.

Set the Service directive as shown in the following examples. (Each directive must appear on a single line in the proxy configuration file; these examples sometimes contain line breaks for readability.)
  • For AIX®:
    Service  /WES_External_Adapter  /opt/ibm/edge/cp/lib/plugins/
    dynacache/libdyna_plugin.o:exec_dynacmd
  • For Solaris:
    Service  /WES_External_Adapter  /opt/ibm/edge/cp/lib/plugins/
    dynacache/libdyna_plugin.so:exec_dynacmd
  • For Linux:
    Service  /WES_External_Adapter  /usr/lib/libdyna_plugin.so:exec_dynacmd
  • For Windows:
    Service  /WES_External_Adapter  C:\Program Files\IBM\edge\cachingproxy\cp\bin\plugins\
    dynacache\dyna_plugin.dll:exec_dynacmd 
If Caching Proxy software is installed in a directory other than the default, substitute your installation path for the path in these examples.

Set the ExternalCacheManager directive to specify file sources

Each Caching Proxy must also be configured to recognize the source of the dynamically generated files. Add an ExternalCacheManager directive to the ibmproxy.conf file for each application server that caches dynamically generated content at this proxy server. This directive specifies a WebSphere Application Server that caches results at the proxy, and sets a maximum expiration time for content from that server.

The server ID used in the ExternalCacheManager directive must match the group ID used in the external cache group stanza of the application server's dynacache.xml file.

For the previous example, add the following entry to each proxy's ibmproxy.conf file.
ExternalCacheManager   IBM-edge-cp-XYZ-1  20 seconds

The Caching Proxy caches only contents from a IBM WebSphere Application Server whose group ID matches an ExternalCacheManager entry in the ibmproxy.conf file.


Icon that indicates the type of topic Reference topic



Timestamp icon Last updated: March 23, 2018 0:18
File name: jspcaching.html