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.
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.
- 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.
- 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.)
- 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.
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.
?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
>
]>
- 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:
This entry spans a single line in the dynacache.xml file.member address ="" \ adapterBeanName="com.ibm.websphere.edge.dynacache.WteAdapter">
- 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.
- 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.
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.
- 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.
- 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
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.
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.