Oracle9i Application Server Best Practices Release 1 (v1.0.2.2) Part Number A95201-01 |
|
This chapter first provides an overview of Oracle9iAS Web Cache and discusses its integration with third-party application servers from a general perspective, followed by detailed examples involving three particular application servers.
This chapter contains these topics:
Oracle9iAS Web Cache is the industry's first caching solution designed from the ground up for e-business. With its unique combination of server acceleration and server load balancing, Oracle9iAS Web Cache tears down the performance barriers that plague today's dynamic e-business Web sites. Unlike legacy cache servers which handle only static data, Oracle9iAS Web Cache accelerates the delivery of both static and dynamically generated Web content, thereby improving response times for feature-rich pages.
As the first and only caching solution on the market to support Edge Side Includes (ESI) for performing page assembly in edge servers, Oracle9iAS Web Cache leads the industry with its ability to deliver rich, personalized content from both the edge of the data center and the edge of the Internet.
Deployed before a farm of application Web servers or globally at the network edge, Oracle9iAS Web Cache also provides load balancing, failover, and patent-pending surge protection features for Web servers. These features combine to ensure blazing Web-site performance and rock-solid uptime while reducing the cost of doing business online. With Oracle9iAS Web Cache, e-businesses can now serve compelling content faster, to more customers, using fewer computing resources than ever before.
Oracle9iAS Web Cache sits in front of application Web servers, caching their content and providing that content to Web browsers that request it. Oracle9iAS Web Cache intercepts all requests from the Web browser to the Web site. If the requested objects are present in the cache, then Oracle9iAS Web Cache sends them to the Web browser. If the requested objects are not in the cache (known as a cache miss), then Oracle9iAS Web Cache forwards the requests via HTTP to the Web server.
Because Oracle9iAS Web Cache is transparent to the Web server, the Web server treats HTTP requests from Oracle9iAS Web Cache as any other HTTP request coming directly from the browser client. In turn, the Web server generates the response (for example using ASP, PSP, or Java servlet) and sends it back to Oracle9iAS Web Cache as an HTTP message.
Oracle9iAS Web Cache then caches any cacheable objects returned by the Web server and forwards the response back to the browser. As Oracle9iAS Web Cache becomes populated, it is able to serve more of the requested content itself, freeing up processing resources on application Web servers and database servers.
Because Oracle9iAS Web Cache fully supports HTTP, it can work with any HTTP-compliant application Web server. How the application Web servers choose to generate HTTP responses is irrelevant to Oracle9iAS Web Cache.
The type of Web server that a site uses depends mainly on the types of applications that site is running. For example, if customers want to run Active Server Pages (ASP), then they may prefer to use Microsoft Internet Information Server (IIS) as the Web server.
This section contains these topics:
You configure Oracle9iAS Web Cache to communicate with a third-party application Web server the same way you would with Oracle HTTP Server, by providing the host name and the listening port number. The default values for the listening ports for the products discussed in this chapter are given in Table 5-1.
Application Web Server | Port |
---|---|
BEA WebLogic 6.0 |
7001 |
IBM HTTP Server / IBM WebSphere 3.5.2 |
80 |
Microsoft IIS 5.0 |
80 |
To configure Oracle9iAS Web Cache to communicate with a third-party application Web server:
webcachectl start
http://web_cache_hostname:4000/webcacheadmin
When prompted, enter administrator
for the administrator user name and administrator
for the password (the first time you log in).
The Application Web Servers page appears in the right pane.
The Edit/Create Application Web Server page dialog box appears.
The Oracle Web Cache Operations page appears in the right pane.
You assign cacheability rules and expiration rules when using third-party application Web servers in the same way as when using Oracle HTTP Server. You can select to cache or not to cache content for:
You can also assign an expiration time limit to documents or invalidate documents at any time.
The following sections describe how to specify cacheability rules and expiration rules for each example. For more information about specifying rules, refer to the Oracle9iAS Web Cache Administration and Deployment Guide in the Oracle9i Application Server Documentation Library.
For this demonstration, we used an evaluation copy of WebLogic 6.0 running on Microsoft Windows NT and Oracle9iAS Web Cache release 2.0.0. The WebLogic 6.0 installation includes a number of JSP, servlet, and EJB examples. For the purposes of this demonstration, we used:
SnoopServlet demonstrates getting and using request information, headers, and parameters sent by the browser. We will use it to demonstrate how Oracle9iAS Web Cache caches full-page dynamic content.
Before you start, ensure that Oracle9iAS Web Cache has been configured to communicate with the WebLogic 6.0 Application Server as described in "Web-site Configuration". Next, start the WebLogic 6.0 Examples Server and access the following URL:
http://hostname:7001/examplesWebApp/SnoopServlet
When you access the URL, notice that your browser displays request information, headers, parameters, and the GIF image "Build On bea".
To cache this content, you need two rules: one to cache the GIF image and one to cache the SnoopServlet output. The rule for the GIF is configured as a default rule with Oracle9iAS Web Cache release 2.0.0. To create the rule for the SnoopServlet output, follow procedure "Configuring Cacheability Rules" in "Creating Rules for Cached Content" in the Oracle9iAS Web Cache Administration and Deployment Guide in the Oracle9i Application Server Documentation Library.
When creating the cacheability rule, ensure that the following steps are performed:
The Edit Cacheability Rule dialog box appears.
/examplesWebApp/SnoopServlet
As a part of this demonstration, verbose mode will be needed in the Web Cache Event Log settings. To turn on verbose event logging:
The Event Logging page appears.
The Change Options for Event Logging dialog box appears.
Now, rather than pointing your browser to the WebLogic 6.0 Application Server, point your browser to Oracle9iAS Web Cache and access the following URL:
http://web_cache_hostname:1100/examplesWebApp/SnoopServlet
The output is the same as it was when you accessed the SnoopServlet directly from the WebLogic 6.0 Application Server. But this time, Oracle9iAS Web Cache caches the SnoopServlet output and serves the request to the client.
One way to verify this is to look at the Oracle9iAS Web Cache Event Log file:
$ORACLE_HOME/webcache/logs/event_log
In our test, the following entries were made in the log based on the cacheability rules defined in the previous steps:
06/Jun/2001:08:56:13 -0800 -- uri /examplesWebApp/SnoopServlet matches cacheable rule /examplesWebApp/SnoopServlet 06/Jun/2001:08:56:13 -0800 -- cache inserted one file '/examplesWebApp/SnoopServlet gzip' in bucket 31450 06/Jun/2001:08:56:13 -0800 -- uri /examplesWebApp/images/BEA_Button_Final_ web.gif matches cacheable rule \.gif$ 06/Jun/2001:08:56:13 -0800 -- cache inserted one file '/examplesWebApp/images/BEA_Button_Final_web.gif' in bucket 86754
From this point on, anytime a client accesses the SnoopServlet, the response will be served from Oracle9iAS Web Cache.
SessionServlet provides a simple example of an HTTP servlet that uses the HttpSession class to track the number of times that a client has visited the servlet. We will use it to demonstrate how Oracle9iAS Web Cache caches pages with session-encoded URLs.
Before you run this example, ensure that Oracle9iAS Web Cache has been configured to communicate with the WebLogic 6.0 Examples Server as described in "Web-site Configuration".
Next, configure your browser not to accept cookies. This is required in order to use session-encoded URLs in this example. Finally, start the WebLogic 6.0 Examples Server and access the following URL:
http://hostname:7001/examplesWebApp/SessionServlet
When you access the URL, notice that the page displays how many times a client has visited it. When you click the link labeled "here", notice that the session ID is encoded in the URL. Every time you refresh or reload the page, the counter increases by one.
To cache the content of the "here" page, create expiration and session-related caching rules for the SessionServlet output.
To create the expiration rule, follow procedure "Configuring Expiration Rules" in "Creating Rules for Cached Content" in the Oracle9iAS Web Cache Administration and Deployment Guide in the Oracle9i Application Server Documentation Library. In the Create Expiration Rule dialog box, elect to expire the output 60 seconds after cache entry. In the After Expiration section, select Remove immediately.
To create a session-related caching rule, follow procedure "Configuring Rules for Pages with Session Tracking" in "Creating Rules for Cached Content" in the Oracle9iAS Web Cache Administration and Deployment Guide in the Oracle9i Application Server Documentation Library. When configuring a session-related caching rule, ensure that the following steps are performed:
Turn on verbose event logging, apply changes, and restart Oracle9iAS Web Cache, as described in "WebLogic SnoopServlet".
Now, rather than pointing your browser to the WebLogic 6.0 Application Server, point your browser to Oracle9iAS Web Cache and access the following URL:
http://web_cache_hostname:1100/examplesWebApp/SessionServlet
The output is the same as it was when you accessed the SessionServlet servlet directly from the WebLogic 6.0 Application Server. This time Oracle9iAS Web Cache caches the SessionServlet output. When the page is refreshed or reloaded, notice that the counter does not increment by one. This is because Oracle9iAS Web Cache serves the content, and the request never goes to the WebLogic 6.0 Application Server.
Another way to verify this is to look at the Oracle9iAS Web Cache Event Log file:
$ORACLE_HOME/webcache/logs/event_log
In our test, the following entries were made in the log based on the cacheability rules defined in the previous steps:
06/Jun/2001:14:29:45 -0800 -- uri /examplesWebApp/SessionServlet;jsessionid=OtS9hLGk0sB8mZdM9NpIs2kFQuHIkhPmjz i3i46zt2HCY22gXf65!1555932292067982192!-1979543882!7001!7002 matches cacheable rule /examplesWebApp/SessionServlet 06/Jun/2001:14:29:45 -0800 -- cache inserted one file '/examplesWebApp/SessionServlet;jsessionid=@ JSESSIONID'in bucket 51355
When reloading the page, you should also notice that the cached response appears faster than when you access the WebLogic server directly.
Because the expiration rule for this URL is set to 60 seconds, Oracle9iAS Web Cache will expire the cached content after 60 seconds and refresh the content the next time the user requests the page.
For this demonstration, we used an evaluation copy of WebSphere 3.5.2 running on Microsoft Windows NT and Oracle9iAS Web Cache release 2.0.0. The WebSphere installation includes a number of JSP, servlet, and EJB examples. For the purposes of this demonstration, we used:
WebSphere Snoop Servlet demonstrates getting and using request information, headers, and parameters sent by the browser. With this example, we will demonstrate how Oracle9iAS Web Cache caches full-page dynamic content.
Before you start, ensure that Oracle9iAS Web Cache has been configured to communicate with the WebSphere 3.5.2 Application Server as described in "Web-site Configuration".
Next, start the WebSphere 3.5.2 server and access the following URL:
http://hostname/servlet/snoop
When you access the URL, notice that request information, headers, and parameters sent by your browser are displayed.
To cache this content, create a cacheability rule for the WebSphere Snoop Servlet output. To create the rule, follow the procedures for "Configuring Cacheability Rules" in "Creating Rules for Cached Content" in the Oracle9iAS Web Cache Administration and Deployment Guide in the Oracle9i Application Server Documentation Library.
When creating the cacheability rule, ensure that the following steps are performed:
The Edit Cacheability Rule dialog box appears.
/servlet/snoop
Turn on verbose event logging, accept changes, and restart Oracle9iAS Web Cache, as described earlier in "WebLogic SnoopServlet".
Now, rather than pointing your browser to the WebSphere 3.5.2 Application Server, point your browser to Oracle9iAS Web Cache and access the following URL:
http://web_cache_hostname:1100/servlet/snoop
The output is the same as it was when you accessed the WebSphere Snoop Servlet directly from the WebSphere Application Server. This time, Oracle9iAS Web Cache caches the output and serves the response to your browser. One way to verify this is to look at the Oracle9iAS Web Cache Event Log file:
$ORACLE_HOME/webcache/logs/event_log
In our test, the following entries were made into the log file based on the cacheability rule defined in the previous steps:
13/Jun/2001:08:33:23 -0800 -- uri /servlet/snoop matches cacheable rule /servlet/snoop 13/Jun/2001:08:33:23 -0800 -- cache inserted one file '/servlet/snoop gzip' in bucket 40796
When you reload the page, you should notice that the cached response appears faster than when you access the WebSphere server directly.
SessionSample is a simple example of an HTTP servlet that tracks the number of times that a client has visited the servlet using a cookie. With this example, we will demonstrate how Oracle9iAS Web Cache caches pages with session cookies.
This example is not a pre-deployed WebSphere example like Snoop Servlet. You can find this example in "section 4.4.1.1: Session programming model and environment" of the WebSphere 3.5 online documentation, when you click on the SessionSample.java
link on that page.
To run this example, first compile the SessionSample.java
file in your WebSphere environment and then copy the SessionSample.class
file in the location where the snoop.class
file resides. The default location for the snoop.class
file is WebSphere's install directory:
\WebSphere\AppServer\hosts\default_host\default_app\serv lets\
Before you run this example, start WebSphere 3.5.2, set your browser to accept cookies, and access the following URL:
http://hostname/servlet/SessionSample
When you access the URL, notice that the page displays the number of times a client has visited this page. When you reload this page, the counter increments by one.
To cache the content of this page, you create expiration and session-related caching rules for the SessionSample servlet output. To do that, you need to know the cookie name that the SessionSample servlet is using. The default cookie name used by the WebSphere 3.5.2 Application Server is sesessionid
. The same cookie name is used in this example.
To create the expiration rule, follow procedure "Configuring Expiration Rules" in "Creating Rules for Cached Content" in the Oracle9iAS Web Cache Administration and Deployment Guide in the Oracle9i Application Server Documentation Library. In the Create Expiration Rule dialog box, elect to expire the output 60 seconds after cache entry. In the After Expiration section, select Remove immediately.
To create a session-related caching rule, follow procedure "Configuring Rules for Pages with Session Tracking" in "Creating Rules for Cached Content" in the Oracle9iAS Web Cache Administration and Deployment Guide in the Oracle9i Application Server Documentation Library. When configuring a session-related caching rule, ensure that the following steps are performed:
Turn on verbose event logging, accept changes, and restart Oracle9iAS Web Cache, as described in "WebLogic SnoopServlet".
Now, rather than pointing your browser to the WebSphere 3.5.2 Application Server, point your browser to Oracle9iAS Web Cache and access the following URL:
http://web_cache_hostname:1100/servlet/SessionSample
The output is the same as when you access the SessionSample servlet directly from WebSphere 3.5.2. This time, Oracle9iAS Web Cache caches the SessionSample servlet output. To verify that the content is served by the cache, refresh or reload the page. Notice that the counter remains the same. This is because Oracle9iAS Web Cache serves the content, and the request never goes to WebSphere 3.5.2.
Another way to verify this is to look at the Web Cache Event Log file:
$ORACLE_HOME/webcache/logs/event_log
In our test, the following entries were made into the log based on thecacheability rules defined in the previous steps:
13/Jun/2001:08:25:54 -0800 -- uri /servlet/SessionSample matches cacheable rule /servlet/SessionSample 13/Jun/2001:08:25:54 -0800 -- cache inserted one file '/servlet/SessionSample sesessionid;gzip' in bucket 72582
When you reload the page, you should also notice that the cached response appears faster than when you access the WebSphere server directly.
The content will expire 60 seconds from the time it was cached, and Oracle9iAS Web Cache will update it the next time it is requested.
For this demonstration, we used an evaluation copy of Microsoft IIS 5.0 running on Microsoft Windows 2000 Server and Oracle9iAS Web Cache release 2.0.0. The installation includes a number of ASP examples. For the purpose of this chapter, we used:
ServerVariables_JScript.asp demonstrates techniques you can use to access server variable information from an ASP script. With this example, we will demonstrate how Oracle9iAS Web Cache caches full-page dynamic content.
Before you start, ensure that Oracle9iAS Web Cache has been configured to communicate with the IIS 5.0 server as described "Web-site Configuration".
Next, start the IIS 5.0 server and access the following URL:
http://hostname/IISSamples/sdk/asp/interaction/ServerVar iables_JScript.asp
When you access the URL, notice that request information, headers, and parameters sent by your browser are displayed.
To cache this content, create a cacheability rule for the ServerVariables_Jscript ASP output. To create the rule, follow procedure "Configuring Cacheability Rules" in "Creating Rules for Cached Content" in the Oracle9iAS Web Cache Administration and Deployment Guide in the Oracle9i Application Server Documentation Library.
When creating the cacheability rule, ensure that the following steps are performed:
The Edit Cacheability Rule dialog box appears.
/IISSamples/sdk/asp/interaction/ServerVariables_JScript.asp
Turn on verbose event logging, accept changes, and restart Oracle9iAS Web Cache, as described in "WebLogic SnoopServlet".
Now, rather than pointing your browser to the Microsoft IIS 5.0 Application Server, point your browser to Oracle9iAS Web Cache and access the following URL:
http://web_cache_hostname:1100/IISSamples/sdk/asp/interaction/ServerVariables_ JScript.asp
The output is the same as it was when you accessed the ServerVariables_Jscript ASP directly from the IIS server. This time, Oracle9iAS Web Cache caches the ServerVariables_Jscript ASP output and serves the request to the client.
To verify this, look at the Oracle9iAS Web Cache Event Log file:
$ORACLE_HOME/webcache/logs/event_log
In our test, the following entries were made in the log file based on the cacheability rule defined in the previous steps:
06/Jun/2001:05:07:39 -0800 -- uri /IISSamples/sdk/asp/interaction/ServerVariables_JScript.asp matches cacheable rule /IISSamples/sdk/asp/interaction/ServerVariables_JScript.asp 06/Jun/2001:05:07:39 -0800 -- cache inserted one file '/IISSamples/sdk/asp/interaction/ServerVariables_JScript.asp gzip' in bucket 12173
Cookie_JScript.asp illustrates how your script can set and read cookies by using the Response.Cookies collection. With this example, we will demonstrate how Oracle9iAS Web Cache caches pages with session cookies.
Before you run this example, ensure that Oracle9iAS Web Cache has been configured to communicate with the IIS 5.0 server as described in "Web-site Configuration".
Next, start the IIS 5.0 server, verify that your browser is set to accept cookies, and access the following URL:
http://hostname/IISSamples/sdk/asp/interaction/Cookie_JS cript.asp
When you access the URL, notice that the page displays the date and time you last visited this page. When you click "Revisit this page", the date and time is updated.
To cache the content of this page, create expiration and session-related caching rules for the Cookie_Jscript output. To do that, you need to know the cookie name that the Cookie_Jscript ASP is using. The default cookie name used by the Microsoft IIS ASP applications is ASPSESSIONID
. The cookie name used in this example is CookieJScript
.
To create the expiration rule, follow procedure "Configuring Expiration Rules" in "Creating Rules for Cached Content" in the Oracle9iAS Web Cache Administration and Deployment Guide in the Oracle9i Application Server Documentation Library. In the Create Expiration Rule dialog box, elect to expire the output 60 seconds after cache entry. In the After Expiration section, select Remove immediately.
To create a session-related caching rule, follow procedure "Configuring Rules for Pages with Session Tracking" in "Creating Rules for Cached Content" in the Oracle9iAS Web Cache Administration and Deployment Guide in the Oracle9i Application Server Documentation Library. When configuring a session-related caching rule, ensure that the following steps are performed:
Turn on verbose event logging, accept changes, and restart Oracle9iAS Web Cache, as described in "WebLogic SnoopServlet".
Now, rather than pointing your browser to the IIS 5.0 server, point your browser to Oracle9iAS Web Cache and access the following URL:
http://web_cache_hostname:1100/IISSamples/sdk/asp/interaction/Cookie_JScript.asp
The output is the same as it was when you accessed the Cookie_JScript directly from Microsoft IIS. This time, Oracle9iAS Web Cache caches the Cookie_JScript output. To verify that the cache serves the content, click "Revisit this page". Notice that the date and time are not updated. This is because Oracle9iAS Web Cache serves the cached content, and the request never goes to Microsoft IIS.
Another way to verify this is to look at the Oracle9iAS Web Cache Event Log file:
$ORACLE_HOME/webcache/logs/event_log
In our test, the following entries were made into the log based on the cacheability rules defined in the previous steps:
06/Jun/2001:04:32:34 -0800 -- uri /IISSamples/sdk/asp/interaction/Cookie_ JScript.asp matches cacheable rule /IISSamples/sdk/asp/interaction/Cookie_ JScript.asp 06/Jun/2001:04:32:34 -0800 -- cache inserted one file '/IISSamples/sdk/asp/interaction/Cookie_JScript.aspgzip' in bucket 92163
The content will expire 60 seconds from the time it was cached, and Oracle9iAS Web Cache will update it the next time it is requested.
|
Copyright © 2001 Oracle Corporation. All Rights Reserved. |
|