7 Managing Virtual Servers

You can use multiple virtual servers within a single Oracle Traffic Director instance to provide several entry points—domain names and IP addresses—for client requests, and to offer differentiated services for caching, quality of service, and so on. You can bind virtual servers to one or more listeners—HTTP or HTTPS—and configure them to forward requests to different origin-server pools.

You can configure caching, compression, routing, quality of service, log-file and web application firewall settings individually for each virtual server.

This chapter describes how to create, view, modify, and delete virtual servers, and configure caching. It contains the following sections:

Creating Virtual Servers

When you create a configuration, a virtual server is created automatically with the same name as that of the configuration and is associated with the HTTP listener that was specified while creating the configuration. A default routing rule is also created for the virtual server, to distribute all requests received at the associated HTTP listener to the origin servers that were specified while creating the configuration.

You can create additional virtual servers in a configuration by using either Fusion Middleware Control or WLST as described in the following topics:

Note:

When you create a virtual server, you are, in effect, modifying a configuration. So for the new virtual-server to take effect in the Oracle Traffic Director instances, you should redeploy the configuration as described in Activate Configuration Changes.

Before You Begin

Before you begin creating a virtual server, decide the following:

A unique name for the virtual server. Choose the name carefully; after creating a virtual server, you cannot change its name.
One or more unique listen ports. For information about creating listeners, see Managing Listeners.
The names of the hosts, or the host patterns, for which the virtual server will handle requests.

When a request is received, Oracle Traffic Director determines the virtual server that should process it, by comparing the Host header in the request with the host patterns defined for each virtual server in the configuration.
- The request is routed to the first virtual server that has a host pattern matching the Host header in the request.
- If the Host header in the request does not match the host patterns defined for any of the virtual servers, or if the request does not contain the Host header, the request is routed to the default virtual server that is associated with the HTTP listener through which the request was received.
Note:

When Strict SNI Host Matching is enabled for an HTTP listener, and if for that listener at least one of the virtual servers has certificates, then Oracle Traffic Director returns a 403-Forbidden error to the client, if any of the following conditions is true:
- The client did not send the SNI host extension during the SSL/TLS handshake.
- The request does not have the Host: header.
- The host name sent by the client in the SNI host extension during the SSL/TLS handshake does not match the Host: header in the request.
The name of the origin-server pool to which the virtual server should forward requests. For information about creating origin-server pools, see Managing Origin-Server Pools.

Creating a Virtual Server Using Fusion Middleware Control

To create a virtual server by using the Fusion Middleware Control, do the following:

Log in to Fusion Middleware Control, as described in Displaying Fusion Middleware Control.
Click the WebLogic Domain button at the upper left corner of the page.
Select Administration > OTD Configurations.

A list of the available configurations is displayed.
Select the configuration for which you want to create a virtual server.
Click the Traffic Director Configuration In the Common Tasks pane.
Select Administration > virtual server.
In the Common Tasks pane, click Create.

The New Virtual Server wizard starts.

Figure 7-1 New Virtual Server Wizard

Description of "Figure 7-1 New Virtual Server Wizard"
Follow the on-screen prompts to complete creation of the virtual server by using the details—listener, origin-server pool, and so on—that you decided earlier.

After the virtual server is created, the Results screen of the New Virtual Server wizard displays a message confirming successful creation of the virtual server.
Click Create Virtual Server on the Results screen.
- The details of the virtual server that you just created are displayed on the Virtual Servers page.

Creating a Virtual Server Using WLST

To create a virtual server, run the otd_createVirtualServer command.

For example, the following command creates a virtual server named bar for the configuration foo, and configures the virtual server to forward client requests to the origin-server pool origin-server-pool-1.

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['origin-server-pool'] = 'origin-server-pool-1'
otd_createVirtualServer(props)

For more information, see the otd_createVirtualServer command in the WebLogic Scripting Tool Command Reference for Oracle Traffic Director.

Viewing a List of Virtual Servers

You can view a list of virtual servers by using either Fusion Middleware Control or the WLST.

Viewing List of Virtual Servers Using Fusion Middleware Control

To view a list of virtual servers by using the Fusion Middleware Control, do the following:

Log in to Fusion Middleware Control, as described in Displaying Fusion Middleware Control.
Click the WebLogic Domain button at the upper left corner of the page.
Select Administration > OTD Configurations.

A list of the available configurations is displayed.
Select the configuration for which you want to view virtual server.
Click the Traffic Director Configuration In the Common Tasks pane.
Select Administration > virtual server.

You can view the properties of a virtual server by clicking on its name.

You can view the properties of a virtual server by clicking on its name.

Viewing a List of Virtual Servers Using WLST

To view a list of virtual servers, run the otd_listVirtualServers command, as shown in the following example:

props = {}
props['configuration'] = 'foo'
otd_listVirtualServers(props)

You can view the properties of a virtual server in detail by running the otd_getVirtualServerProperties command.

For more information, see the otd_getVirtualServerProperties and otd_getVirtualServerProperties commands in the WebLogic Scripting Tool Command Reference for Oracle Traffic Director.

Modifying Virtual Server Settings

You can modify virtual servers by using either Fusion Middleware Control or the WLST.

Note:

When you modify a virtual server, you are, in effect, modifying a configuration. So for the new virtual-server settings to take effect in the Oracle Traffic Director instances, you should redeploy the configuration as described in Activate Configuration Changes.

Topics

Modifying a Virtual Server Using Fusion Middleware Control

To modify a virtual server by using the Fusion Middleware Control, do the following:

Log in to Fusion Middleware Control, as described in Displaying Fusion Middleware Control.
Click the WebLogic Domain button at the upper left corner of the page.
Select Administration > OTD Configurations.

A list of the available configurations is displayed.
Select the configuration for which you want to modify virtual server.
Click the Traffic Director Configuration In the Common Tasks pane.
Select Administration > virtual server.

The Virtual Servers page is displayed. It shows a list of the virtual servers defined for the configuration.
Select the virtual server that you want to modify and click Edit button in common tasks pan.
The Virtual Server Settings page is displayed. On this page, you can do the following:
- Enable and disable the virtual server.
- Add, remove, and change host patterns served by the virtual server. For more information about how Oracle Traffic Director uses host patterns, see the Before you begin section.
- Add and remove HTTP listeners. For information about creating HTTP listeners, see Creating a Listener.
- Enable SSL/TLS, by associating an RSA or an ECC certificate (or both) with the virtual server. For more information, see RSA and ECC Certificates.
- Configure the virtual server to serve instance-level statistics in the form of XML and plain-text reports that users can access through a browser. Note that the statistics displayed in the XML and plain-text reports are for the Oracle Traffic Director instance as a whole and not specific to each virtual server. For more information, see Configuring URL Access to Statistics.
- The default language for messages is English. If required, this can be set to other languages that Oracle Traffic Director supports.
- Specify error pages that the virtual server should return to clients for different error codes. This is necessary only if you do not wish to use the default error pages and would like to customize them.
  
  To specify error codes and error pages of your choice, first create html pages that you would like displayed for specific error codes and save them to any directory that can be accessed by the administration server. Next, on the Virtual Server Settings page, in the Error Pages section, click New Error Page.
  
  In the New Error Page dialog box that appears, select an error code and enter the full path to the error page for that particular error code. In addition to the error codes that are provided, you can create your own custom error code by clicking Custom Error Code and entering a value for the same. When done, click Create Error Page.
- Enable and quality of service limits—the maximum speed at which the virtual server should transfer data to clients and the maximum number of concurrent connections that the virtual server can support.
In the navigation pane, under the Virtual Servers node, you can select the following additional categories of settings for the virtual server. The parameters relevant to the selected category are displayed in the main pane.
- Settings: Create, change, and delete rules for routing requests to origin servers. For more information, see Configuring Routes for a Virtual Server.
- Routes: Create, change, and delete rules for routing requests to origin servers.
- Caching: Create, change, and delete rules for caching responses received from origin servers. For more information, see Configuring Caching Parameters.
- Compression: Create, change, and delete rules for compressing responses from origin servers before forwarding them to the clients. For more information, see Enabling and Configuring Content Compression.
- Request Limits: Create, change, and delete rules for limiting the number and rate of requests received by the virtual server.
- Bandwidth Limits: Enable, change, and delete rules for the number of requests received by the virtual server.
- Content Serving: Create, change, and delete rules for static content serving to origin servers.
- Web Application Firewall: Enable or disable web application firewall rule set, specify rule set patterns and install rule set files.
- Logging: Define a server log file and location that is specific to the virtual server. For more information, see Configuring Log Preferences.
Specify the parameters that you want to change.

On-screen help and prompts are provided for all of the parameters.

When you change the value in a field or tab out of a text field that you changed, the Apply button near the upper right corner of the page is enabled.

At any time, you can discard the changes by clicking the Revert button.
After making the required changes, click Apply.
- A message, confirming that the updated configuration was saved, is displayed in the Console Messages pane.

Modifying a Virtual Server Using WLST

WLST provides several commands that you can use to change specific parameters of a virtual server.

Table 7-1 WLST Commands for Modifying a Virtual Server

Task/s	WLST Command/s
Enable or disable a virtual server; change the host, the HTTP listener, name and location of the log file; enable SSL/TLS by associating an RSA, or an ECC certificate, or both (see also: RSA and ECC Certificates and Configuring Log Preferences)	`otd_setVirtualServerProperties`
Create and manage routes (see Configuring Routes)	`otd_createRoute` `otd_listRoutes` `otd_deleteRoute` `otd_setRouteProperties` `otd_getRouteProperties`
Create and manage caching rules (see Caching in Oracle Traffic Director	`otd_createCacheRule` `otd_listCacheRules` `otd_deleteCacheRule` `otd_getCacheRuleProperties` `otd_setCacheRuleProperties`
Create and manage compression rules (see Enabling and Configuring Content Compression)	`otd_createCompressionRule` `otd_setCompressionRuleProperties` `otd_deleteCompressionRule` `otd_listCompressionRules` `otd_getCompressionRuleProperties`
Change request limiting settings	`otd_createRequestLimit` `otd_deleteRequestLimit` `otd_getRequestLimitProperties` `otd_listRequestLimits` `otd_setRequestLimitProperties`
Create and manage content rules (see Content Serving)	`otd_createContentRule` `otd_deleteContentRule` `otd_listContentRules` `otd_setContentRuleProperties` `otd_getContentRuleProperties`
Create and manage error pages	`otd_createErrorPage` `otd_deleteErrorPage` `otd_listErrorPages`

For example, the following command changes the name of the HTTP listener associated with the virtual server bar to http-listener-1.

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['http-listener-name'] = 'http-listener-1'
otd_setVirtualServerProperties(props)

For more information about the WLST commands, see WebLogic Scripting Tool Command Reference for Oracle Traffic Director.

Configuring Routes for a Virtual Server

When you create a configuration, a virtual server is automatically created with the listener that you specified while creating the configuration. For the automatically created virtual server, as well as for any virtual server that you add subsequently in the configuration, a default route is created. The default route rule specifies that all requests to the virtual server should be routed to the origin-server pool that you specified while creating the virtual server. The default route of a virtual server cannot be deleted, but you can change its properties.

You can create additional routes for the virtual server, to route requests that satisfy specified conditions to specific origin-server pools. For example, in a banking software solution, if customer transactions for loans and deposits are processed by separate applications, you can host each of those applications in a separate origin-server pool behind an Oracle Traffic Director instance. To route customer requests to the appropriate origin-server pool depending on whether the request pertains to the loans or deposits applications, you can set up two routes as follows:

Route 1: If the request URI starts with /loan, send the request to the origin-server pool that hosts the loans application.
Route 2: If the request URI starts with /deposit, send the request to the origin-server pool that hosts the deposits application.

When a virtual server that is configured with multiple routes receives a request, it checks the request URI against each of the available routes. The routes are checked in the order in which they were created.

If the request satisfies the condition in a route, Oracle Traffic Director sends the request to the origin-server pool specified for that route.
If the request does not match the condition in any of the defined routes, Oracle Traffic Director sends the request to the origin-server pool specified in the default route.

WebSocket upgrade is enabled by default. In Fusion Middleware Control, use the WebSocket Upgrade check box to enable or disable WebSocket protocol for a route. Similarly, WebSocket protocol can also be enabled or disabled using the websocket-upgrade-enabled property, which can be set using the otd_setRouteProperties WLST command.

You can configure routes in a virtual server by using either Fusion Middleware Control or WLST as described in the following topics:

Configuring Routes Using Fusion Middleware Control

To configure routes by using the Fusion Middleware Control, do the following:

Log in to Fusion Middleware Control, as described in Displaying Fusion Middleware Control.
Click the WebLogic Domain button at the upper left corner of the page.
Select Administration > OTD Configurations.

A list of the available configurations is displayed.
Select the configuration for which you want to configure routes.
Click the Traffic Director Configuration In the Common Tasks pane.
Select Administration > Virtual Servers.

The Virtual Servers page is displayed.
In the navigation pane, expand Virtual Servers, expand the name of the virtual server for which you want to configure routes, and select Routes.

The Routes page is displayed. It lists the routes that are currently defined for the virtual server.
Creating a Route
1. Click Create.
  
  The New Route dialog box is displayed.
  
  In the Name field, enter a name for the new route.
  
  In the Origin Server Pool field, select the origin-server pool to which requests that satisfy the specified condition should be routed.
2. In the Condition Information pane, select a Variable/Function and an Operator from the respective drop-down lists, and provide a value in the Value field.
  
  Select the and/or operator from the drop-down list when configuring multiple expressions. Similarly, use the Not operator when you want the route to be applied only when the given expression is not true.
  
  Click Ok.
  
  To enter a condition manually, click Cancel and then click Edit Expressions, the new window opens, Click Edit Manually. In the Condition field, specify the condition under which the routing rule should be applied. For information about building condition expressions, click the help button near the Condition field or see Using Variables, Expressions, Wildcards, and String Interpolation in Configuration File Reference for Oracle Traffic Director .
3. Click OK.
  
  The route that you just created is displayed on the Routes page.
Editing a Route

To change the settings of a route, do the following:
1. Click the Name and select Edit button for the route.
  
  The Route Settings page is displayed.
2. Specify the parameters that you want to change.
  
  On-screen help and prompts are provided for all of the parameters.
  
  When you change the value in a field or tab out of a text field that you changed, the OK button near the upper right corner of the page is enabled.
  
  At any time, you can discard the changes by clicking the Cancel button.
3. After making the required changes, click OK.
  
  The updated configuration is saved.
Deleting a Route Rule

To delete a route rule, click the Delete button. At the confirmation prompt, click OK.

Configuring Routes Using WLST

To create a route, run the otd_createRoute command.

Examples:

- The following command creates a route named loan-route in the virtual server bar of the configuration foo, to send requests for which the URI matches the pattern /loan to the origin-server pool loan-app.
```
props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['route'] = 'loan-route'
props['origin-server-pool'] = 'loan-app'
props['condition'] = "headers{'content-length'} < 400"
otd_createRoute(props)
```
- The following command creates a route named images-route in the virtual server bar of the configuration foo, to send requests for which the URI path matches the pattern /images to the origin-server pool images-repo.
```
props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['route'] = 'images-route'
props['origin-server-pool'] = 'images-repo'
props['condition'] = '$path='/images/*''
otd_createRoute(props)
```
- The following command creates a route named subnet-route in the virtual server bar of the configuration foo, to send requests from any client in the subnet 130.35.46.* to the origin-server pool dedicated-osp.
```
props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['route'] = 'subnet-route'
props['origin-server-pool'] = 'dedicated-osp'
props['condition'] = '$ip='130.35.46.*''
otd_createRoute(props)
```
- The following command creates a route named body-route in the virtual server bar of the configuration foo, to route requests to the origin-server pool dedicated-osp if the request body contains the word alpha.
```
props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['route'] = 'body-route'
props['origin-server-pool'] = 'dedicated-osp'
props['condition'] = '$body ='alpha''
otd_createRoute(props)
```
Note that the value of the condition property should be a regular expression. For information about building condition expressions, see Using Variables, Expressions, Wildcards, and String Interpolation in Configuration File Reference for Oracle Traffic Director .
To view a list of the routes defined for a virtual server, run the otd_listRoutes command, as shown in the following example:
```
props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
otd_listRoutes(props)
```

To view the properties of a route, run the otd_getRouteProperties command, as shown in the following example:

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['route'] = 'loan-route'
otd_getRouteProperties(props)

keep-alive-timeout=15
sticky-cookie=JSESSIONID
condition="$uri = '/loan'"
validate-server-cert=true
always-use-keep-alive=false
origin-server-pool=origin-server-pool-1
sticky-param=jsessionid
route-header=Proxy-jroute
rewrite-headers=location,content-location
use-keep-alive=true
route=loan-route
log-headers=false
route-cookie=JROUTE
timeout=300

To change the properties of a route, run the otd_setRouteProperties command.

Examples:
- The following command changes the websocket idle timeout setting for the route named route-1 in the virtual server bar of the configuration foo to 1200 seconds.
```
props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['route'] = 'route-1'
props['websocket-idle-timeout'] = '1200'
otd_setRouteProperties(props)
```
- The following command enables logging of the headers that Oracle Traffic Director sends to, and receives from, the origin servers associated with the route named default-route in the virtual server bar of the configuration foo.
```
props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['route'] = 'default-route'
props['log-headers'] = 'true'
otd_setRouteProperties(props)
```

To disable WebSocket support, run the otd_setRouteProperties command with the websocket-upgrade-enabled property, as shown in the following example:

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['route'] = 'default-route'
props['websocket-upgrade-enabled'] = 'false'
otd_setRouteProperties(props)

To delete a route, run the otd_deleteRoute command, as shown in the following example:

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['route'] = 'route-1'
otd_deleteRoute(props)

For more information about the WLST commands mentioned in this section, see WebLogic Scripting Tool Command Reference for Oracle Traffic Director.

Copying a Virtual Server

You can copy a virtual server by using either Fusion Middleware Control or the WLST.

Note:

When you copy a virtual server, you are, in effect, modifying a configuration. So for the new virtual server to take effect in the Oracle Traffic Director instances, you should redeploy the configuration as described in Activate Configuration Changes.

Copying a Virtual Server Using Fusion Middleware Control

To copy a virtual server by using the Fusion Middleware Control, do the following:

Log in to Fusion Middleware Control, as described in Displaying Fusion Middleware Control.
Click the WebLogic Domain button at the upper left corner of the page.
Select Administration > OTD Configurations.

A list of the available configurations is displayed.
Select the configuration for which you want to copy virtual server.
Click the Traffic Director Configuration In the Common Tasks pane.
Select Administration > virtual server.

The Virtual Servers page is displayed. It shows a list of the virtual servers defined for the configuration.
Click the Duplicate icon for the virtual server that you want to copy.

The Duplicate Virtual Server dialog box is displayed.
Enter a name for the new virtual server, and click OK.

A message is displayed confirming that the new virtual server was created.

Copying a Virtual Server Using WLST

To copy a virtual server, run the otd_copyVirtualServer command.

For example, the following command creates a copy (baz) of the virtual server bar.

props = {}
props['configuration'] = 'foo'
props['source-virtual-server'] = 'bar'
props['dest-virtual-server'] = 'baz'
otd_copyVirtualServer(props)

For more information, see otd_copyVirtualServer command in the WebLogic Scripting Tool Command Reference for Oracle Traffic Director.

Deleting a Virtual Server

You can delete virtual servers by using either Fusion Middleware Control or the WLST.

Deleting a Virtual Server Using Fusion Middleware Control

To delete a virtual server by using the Fusion Middleware Control, do the following:

Log in to Fusion Middleware Control, as described in Displaying Fusion Middleware Control.
Click the WebLogic Domain button at the upper left corner of the page.
Select Administration > OTD Configurations.

A list of the available configurations is displayed.
Select the configuration for which you want to delete virtual server.
Click the Traffic Director Configuration In the Common Tasks pane.
Select Administration > virtual server.

The Virtual Servers page is displayed. It shows a list of the virtual servers defined for the configuration.
Click the Delete icon for the virtual server that you want to delete.

A prompt to confirm the deletion is displayed.
Click OK.

A message is displayed in the Console Message pane confirming that the virtual server was deleted.

Deleting a Virtual Server Using WLST

To delete a virtual server, run the otd_deleteVirtualServer command, as shown in the following example:

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
otd_deleteVirtualServer(props)

For more information, see otd_deleteVirtualServer command in the WebLogic Scripting Tool Command Reference for Oracle Traffic Director.

Caching in Oracle Traffic Director

Caching frequently requested data reduces the time that clients have to wait for responses. In addition, when frequently accessed objects (response body and headers) are stored in memory, the load on the origin servers is significantly reduced.

To enable caching, you must configure caching rules.

Both static and dynamically generated content from origin servers are cached.
Only Successful responses (response code: 200) are cached.
Responses to only HTTP GET and HEAD requests are cached.
Oracle Traffic Director caches the response body and all of the response headers except Dest-IP, Proxy-Agent, Proxy-Connection, Server, Set-Cookie, State-Info, and Status.
Oracle Traffic Director honors Cache-Control directives from origin servers, including directives to revalidate content and to not cache certain headers.
You can configure one or more caching rules specific to each virtual server, subject to the overall limits—maximum heap space, maximum entries, and maximum object size—specified for the configuration.

You can configure the caching rules to be applicable either to all requests or to only those requests that match a specified condition.
Cached data is held in the process memory (heap), separately for each virtual server. When the instance is stopped or restarted, the cache becomes empty.
WebSocket upgrade requests are not cached.

When a client first requests an object, Oracle Traffic Director sends the request to an origin server. This request is a cache miss. If the requested object matches a caching rule, Oracle Traffic Director caches the object. For subsequent requests for the same object, Oracle Traffic Director serves the object from its cache to the client. Such requests are cache hits.

The caching behavior in Oracle Traffic Director is consistent with the specification in section 13 of RFC 2616. For more information, see http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html.

Reviewing Cache Settings and Metrics for an Instance

Viewing Caching Settings

To view the current caching settings for a configuration, run the otd_getCacheProperties command, as shown in the following example:

props = {}
props['configuration'] = 'foo'
otd_getCacheProperties(props)

enabled=true
max-entries=1024
replacement=lru
max-heap-object-size=524288
max-heap-size=10485760

To view a list of the caching rules defined for a virtual server, run the otd_listCacheRules command, as shown in the following example:
```
props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
otd_listCacheRules(props)
```
```
cache-rule-1
cache-rule-2 
```

To view the current settings of a virtual server-specific caching rule, run the otd_getCacheRuleProperties command, as shown in the following example:

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['cache-rule'] = 'cache-rule-1'
otd_getCacheRuleProperties(props)

condition="$uri = '^/images"
enabled=true
max-reload-interval=3600
min-reload-time=0
last-modified-factor=0
min-object-size=1
cache-https-response=true
rule=cache-rule-2
query-maxlen=0
compression=true
cache-http-response=false

Viewing Caching Metrics

You can view the current cache-hit rate, the cache heap usage, and the rate of successful revalidation of cache entries in the plain-text perfdump report, as shown in the following example:

Proxy Cache:
---------------------------
Proxy Cache Enabled              yes
Object Cache Entries             42
Cache lookup (hits/misses)       183/79
Requests served from Cache       22
Revalidation (successful/total)  30/38 (  78.95%)
Heap space used                  16495

Proxy Cache Enabled indicates whether caching is enabled for the instance.
Object Cache Entries is the number of entries (URIs) currently in the cache.
Cache lookup (hits/misses)
- The first number is the number of times an entry was found in the cache for the requested URI.
- The second number is the number of times the requested URI was not found in the cache.
Requests served from Cache is the number of requests that Oracle Traffic Director served from the cache.
Revalidation (successful/total)
- The first number is the number of times revalidation of cached content was successful.
- The second number is the total number of times Oracle Traffic Director attempted to revalidate cached content.
- The percentage value is the ratio of successful revalidations to the total number of revalidation attempts.
Heap space used is the amount of cache heap space that is currently used.

Tunable Caching Parameters

Caching can be considered effective in reducing the response time for clients when the cache-hit rate is high; that is, a relatively large number of requests are served from the cache instead of being sent to origin servers. For a high cache-hit rate, there should be sufficient memory to store cacheable responses from origin servers and the entries in the cache should be validated regularly.

Note:

Dynamic content is generally not cacheable. So if the application or content being served by the origin servers consists mostly of dynamic content, the cache-hit rate is bound to be low. In such cases, enabling and tuning caching might not yield a significant performance improvement.

To improve the cache-hit rate, you can tune the following caching parameters:

Cache-entry replacement method

When the cache becomes full—that is, the number of entries reaches the maximum entries limit, or the cache heap size reaches the maximum cache heap space—further entries in the cache can be accommodated only if existing entries are removed. The cache-entry replacement method specifies how Oracle Traffic Director determines the entries that can be removed from the cache.
- The default replacement method is Least Recently Used (lru). When the cache is full, Oracle Traffic Director discards the least recently used entries first.
- The other available method is Least Frequently Used (lfu). When the cache is full, Oracle Traffic Director discards the least frequently used entry first.
In either method, every time Oracle Traffic Director serves content from the cache, it needs to track usage information—the time the content was served in the case of the lru replacement method, and the number of times the content was served in the case of lfu. So the time saved by serving content directly from the cache instead of sending the request to the origin server, is offset to a certain extent by the latency caused by the need to track usage information. Between the two methods, lru requires marginally lower computing resources.

You can disable cache-entry replacement by specifying false as the replacement method.
Maximum cache heap space

If only a small portion of the available heap space is used, it is possible that responses are not being cached because the virtual server-specific caching rules are defined too narrowly.

The optimal cache heap size depends upon how much system memory is free. With a large cache heap, Oracle Traffic Director can cache more content and therefore obtain a better hit ratio. However, the heap size should not be so large that the operating system starts paging cached content.
Maximum number of entries in the cache

If the number of entries in the cache, as shown in the perfdump report, is consistently near, or at, the maximum number of entries, it is an indication that the cache might not be large enough. Consider increasing the maximum number of entries.

If the number of entries in the cache is very low when compared with the maximum allowed entries, it is possible that responses are not being cached because the virtual server-specific caching rules are defined too narrowly.
Maximum size of cacheable object

To conserve system resources, you can limit the size of objects that are cached, even if the objects fulfill other caching rules.

If you observe that objects that are larger than the maximum cached object size are requested frequently, consider increasing the limit.

In a caching rule for a specific virtual server, you can specify the following parameters:

Minimum and maximum size of objects that can be cached
Minimum and maximum interval between cache-validation checks
Maximum number of characters in a query string that can be cached
Whether to compress content before caching
Whether to cache HTTPS responses

Configuring Caching Parameters

You can configure caching settings by using either Fusion Middleware Control or the WLST.

Configuring Caching Settings Using Fusion Middleware Control

To configure caching settings by using the Fusion Middleware Control, do the following:

Log in to Fusion Middleware Control, as described in Displaying Fusion Middleware Control.
Click the WebLogic Domain button at the upper left corner of the page.
Select Administration > OTD Configurations.

A list of the available configurations is displayed.
Select the configuration for which you want to modify.
Click the Traffic Director Configuration In the Common Tasks pane.
Select Administration > Virtual Servers.

The Virtual Servers page is displayed.
In the navigation pane, expand Virtual Servers, expand the name of the virtual server for which you want to configure cache, and select Caching.

The Cache Rules page is displayed. It lists the Cache rules that are currently defined for the virtual server.
In the navigation pane, select Advanced Settings.

The Advanced Settings page is displayed.
Specify the caching parameters that you want to change.

On-screen help and prompts are provided for all of the parameters.

When you change the value in a field or tab out of a text field that you changed, the OK button near the upper right corner of the page is enabled.

At any time, you can discard the changes by clicking the Cancel button.
After making the required changes, click OK.
- A message, confirming that the updated configuration was saved, is displayed in the Console Messages pane.

Configuring Virtual Server-Specific Caching Rules Using Fusion Middleware Control

To create virtual server-specific caching rules by using the Fusion Middleware Control, do the following:

Log in to Fusion Middleware Control, as described in Displaying Fusion Middleware Control.
Click the WebLogic Domain button at the upper left corner of the page.
Select Administration > OTD Configurations.

A list of the available configurations is displayed.
Select the configuration for which you want to create virtual server-specific caching rules.
Click the Traffic Director Configuration In the Common Tasks pane.
Select Administration > Virtual Servers.

The Virtual Servers page is displayed.
In the navigation pane, expand Virtual Servers, expand the name of the virtual server for which you want to create caching rules, and select Caching.

The Caching page is displayed. It lists the caching rules that are currently defined for the virtual server, and indicates whether the rules are enabled.

Creating a Caching Rule
1. Click New Caching Rule.
  
  The New Cache Rule dialog box is displayed.
  
  In the Name field, enter a name for the new caching rule.
2. Click Ok.
  
  The caching rule that you just created is displayed on the Caching page.
Editing a Caching Rule

To enable or disable a caching rule, or to change the settings of a rule, do the following:
1. Click the Name of the caching rule that you want to edit.
  
  The Edit Cache Rule dialog box is displayed.
  
  Note:
  
  To access the condition builder to edit conditions, select Requests satisfying the condition and click Edit. The condition builder enables you to delete old expressions and add new ones.
2. Specify the parameters that you want to change.
  
  On-screen help and prompts are provided for all of the parameters.
  
  For information about building condition expressions, click the help button near the Condition field or see Using Variables, Expressions, and String Interpolation command in the Configuration File Reference for Oracle Traffic Director .
  
  When you change the value in a field or tab out of a text field that you changed, the Save button near the upper right corner of the page is enabled.
  
  At any time, you can discard the changes by clicking the Reset button.
3. After making the required changes, click Save.
  
  A message, confirming that the updated configuration was saved, is displayed in the Console Messages pane.
Deleting a Caching Rule

To delete a caching rule, click the Delete button. At the confirmation prompt, click OK.

Configuring Caching Settings Using WLST

To change the caching properties for a configuration, run the otd_setCacheProperties command.

For example, the following command changes the maximum cache heap space to 20 MB.
```
props = {}
props['configuration'] = 'foo'
props['max-heap-space'] = '20971520'
otd_setCacheProperties(props)
```
To create a caching rule for a virtual server, run the otd_createCacheRule command.

For example, the following command creates a rule named cache-rule-images for the virtual server bar in the configuration foo, to cache the requests for which the expression $uri='^/images' evaluates to true.
```
props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['cache-rule'] = 'cache-rule-images'
props['condition'] = '$uri='^/images''
otd_createCacheRule(props)
```
Note that the value of the condition property should be a regular expression. For information about building condition expressions, see Using Variables, Expressions, and String Interpolation command in the Configuration File Reference for Oracle Traffic Director .

To change a caching rule, run the otd_setCacheRuleProperties command.

For example, the following command disables compression of content for the caching rule cache-rule-images.

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['cache-rule'] = 'cache-rule-images'
props['compression'] = 'false'
otd_setCacheRuleProperties(props)

To delete a caching rule, run the otd_deletecacheRule command, as shown in the following example.

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['cache-rule'] = 'cache-rule-1'
otd_deleteCacheRule(props)

For more information about the WLST commands mentioned in this section, see WebLogic Scripting Tool Command Reference for Oracle Traffic Director.

Content Serving

Content-rule supports only static content serving. No dynamic content serving is supported and it can be created only based on uri-prefix. Uri-prefix should be unique across all the content rules. OTD admin supports static content serving only for content-rule, mime types and file cache.

OTD supports static content serving by managing content-rules. No dynamic content serving is supported. Content-rule is created based on uri-prefix and uri-prefix should be unique across all the content-rule.

Configuring Content Serving Using Fusion Middleware Control

To configure content serving by using the Fusion Middleware Control, do the following:

Log in to Fusion Middleware Control, as described in Displaying Fusion Middleware Control.
Click the WebLogic Domain button at the upper left corner of the page.
Select Administration > OTD Configurations.

A list of the available configurations is displayed.
Select the configuration for which you want to configure content serving.
Click the Traffic Director Configuration In the Common Tasks pane.
Select Administration > Virtual Servers.

The Virtual Servers page is displayed.
In the navigation pane, expand Virtual Servers, expand the name of the virtual server for which you want to configure content serving, and select Content serving.

The content serving page is displayed. It lists the content serving that are currently defined for the virtual server.
Creating a Content serving
1. Click Create.
  
  The New Content Serving dialog box is displayed.
  
  In the Name field, enter a name for the new content rule.
2. In the URI Prefix field, enter the specified URI for that content rule.
3. In the Directory Path field, enter the specified directory where all the new content rules are available.
  
  Click OK.
  
  The Content Serving that you just created is displayed on the Content Serving page.
Editing a Content Serving

To change the settings of a Content Serving, do the following:
1. Click the Name and select Edit button for the Content Serving.
  
  The Content Serving Settings page is displayed.
2. Specify the parameters that you want to change.
  
  When you change the value in a field or tab out of a text field that you changed, the OK button near the upper right corner of the page is enabled.
  
  At any time, you can discard the changes by clicking the Cancel button.
3. After making the required changes, click OK.
  
  The updated configuration is saved.
Deleting a Content Serving

To delete a Content Serving rule, click the Delete button. At the confirmation prompt, click OK.

Configuring Content Serving Using WLST

To create a content rule, run the otd_createContentRule command, as shown in the following example:

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['uri-prefix'] = '/baz'
props['directory-path'] = '/qux'
props['content-rule'] = 'content-rule-1'
otd_createContentRule(props)

To view the list of content rules defined for a virtual server, run the otd_listContentRules command, as shown in the following example:
```
props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
otd_listContentRules(props)
```

To view the content rule properties run the otd_getContentRuleProperties command, as shown in the following example:

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['content-rule'] = 'content-rule-1'
otd_getContentRuleProperties(props)

To set content rule properties run the otd_setContentRuleProperties command, as shown in the following example:

props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['content-rule'] = 'content-rule-1'
props['index-files'] = 'home.htm'
otd_setContentRuleProperties(props)

To delete a content rule, run the otd_deleteContentRule command, as shown in the following example:

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['content-rule'] = 'content-rule-1'
otd_deleteContentRule(props)

To create a mime type, run the otd_createMimeType command, as shown in the following example:

props = {}
props['configuration'] = 'foo'
props['content-type'] = 'bar'
props['extensions'] = 'baz'
otd_createMimeType(props)

To view the list of mime types, run the otd_listMimeTypes command, as shown in the following example:
```
props = {}
props['configuration'] = 'foo'
otd_listMimeTypes(props)
```

To delete a mime type, run the otd_deleteMimeType command, as shown in the following example:

props = {}
props['configuration'] = 'foo'
props['content-type'] = 'bar'
props['extensions'] = 'baz'
otd_createMimeType(props)

To view the file cache properties run the otd_getFileCacheProperties command, as shown in the following example:
```
props = {}
props['configuration'] = 'foo'
otd_getFileCacheProperties(props)
```
To set File Cache properties run the otd_setFileCacheProperties command, as shown in the following example:
```
props = {}
props['configuration'] = 'foo'
props['max-age'] = '1200'
otd_setFileCacheProperties(props)
```

For more information about the WLST commands mentioned in this section, see WebLogic Scripting Tool Command Reference for Oracle Traffic Director.