| Oracle® Traffic Director Administrator's Guide 11g Release 1 (11.1.1.7.0) Part Number E21036-04 |
|
|
PDF · Mobi · ePub |
| Oracle® Traffic Director Administrator's Guide 11g Release 1 (11.1.1.7.0) Part Number E21036-04 |
|
|
PDF · Mobi · ePub |
This section contains the following topics:
Caching frequently requested data reduces the time that clients have to wait for responses. In addition, when frequently accessed URLs are stored in memory, the load on the origin servers is significantly reduced.
Caching is enabled by default in Oracle Traffic Director.
Both static and dynamically generated content from origin servers are cached.
Only complete 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.
To view the current caching settings for a configuration, run the get-cache-prop command, as shown in the following example:
tadm> get-cache-prop --config=soa
enabled=true
replacement=lru
max-heap-space=10485760
max-entries=1024
max-heap-object-size=524288
To view a list of the caching rules defined for a virtual server, run the list-cache-rules command, as shown in the following example:
tadm> list-cache-rules --config=soa --vs=soa --verbose --all
rule condition
-------------------------
cache-rule-2 "$uri = '^/images'
cache-rule-1 -
To view the current settings of a virtual server-specific caching rule, run the get-cache-rule-prop command, as shown in the following example:
tadm> get-cache-rule-prop --config=soa --vs=soa --rule=cache-rule-2
enabled=true
last-modified-factor=0
min-object-size=1
cache-https-response=true
condition="$uri = '^/images"
min-reload-interval=0
rule=cache-rule-2
query-maxlen=0
compression=true
max-reload-interval=3600
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.
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
You can configure caching settings by using either the administration console or the CLI.
Configuring Caching Settings Using the Administration Console
To configure caching settings by using the administration console, do the following:
Log in to the administration console, as described in Section 2.3.2, "Accessing the Administration Console."
Click the Configurations button that is situated at the upper left corner of the page.
A list of the available configurations is displayed.
Select the configuration that you want to modify.
In the navigation pane, select Advanced Settings.
The Advanced Settings page is displayed.
Go to the Cache section on the page.
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 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.
After making the required changes, click Save.
A message, confirming that the updated configuration was saved, is displayed in the Console Messages pane.
In addition, the Deployment Pending message is displayed at the top of the main pane. You can either deploy the updated configuration immediately by clicking Deploy Changes, or you can do so later after making further changes as described in Section 4.3, "Deploying a Configuration."
Configuring Virtual Server-Specific Caching Rules Using the Administration Console
To create virtual server-specific caching rules by using the administration console, do the following:
Log in to the administration console, as described in Section 2.3.2, "Accessing the Administration Console."
Click the Configurations button that is situated at the upper left corner of the page.
A list of the available configurations is displayed.
Select the configuration for which you want to create virtual server-specific caching rules.
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
Click New Caching Rule.
The New Cache Rule dialog box is displayed.
In the Name field, enter a name for the new caching rule.
Click Next.
If this is the first caching rule for the virtual server, the New Caching Rule dialog box gives you the option to choose whether the rule should be applied to all requests. Select All Requests.
If you wish to apply the rule to only those requests that satisfy a condition, create a new condition by selecting Create a new condition. In the condition builder, 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.
To enter a condition manually, click Cancel and then click Edit Manually. In the Condition field, specify the condition under which the caching rule should be applied. For information about building condition expressions, click the help button near the Condition field or see "Using Variables, Expressions, and String Interpolation" in the Oracle Traffic Director Configuration Files Reference.
Click Next and then click Create Caching Rule.
The caching rule that you just created is displayed on the Caching page.
In addition, the Deployment Pending message is displayed at the top of the main pane. You can either deploy the updated configuration immediately by clicking Deploy Changes, or you can do so later after making further changes as described in Section 4.3, "Deploying a Configuration."
Editing a Caching Rule
To enable or disable a caching rule, or to change the settings of a rule, do the following:
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.
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" in the Oracle Traffic Director Configuration Files Reference.
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.
After making the required changes, click Save.
A message, confirming that the updated configuration was saved, is displayed in the Console Messages pane.
In addition, the Deployment Pending message is displayed at the top of the main pane. You can either deploy the updated configuration immediately by clicking Deploy Changes, or you can do so later after making further changes as described in Section 4.3, "Deploying a Configuration."
Deleting a Caching Rule
To delete a caching rule, click the Delete button. At the confirmation prompt, click OK.
Configuring Caching Settings Using the CLI
To change the caching properties for a configuration, run the set-cache-prop command.
For example, the following command changes the maximum cache heap space to 20 MB.
tadm> set-cache-prop --config=soa max-heap-space=20971520
OTD-70201 Command 'set-cache-prop' ran successfully.
To create a caching rule for a virtual server, run the create-cache-rule command.
For example, the following command creates a rule named cache-rule-images for the virtual server soa.example.com in the configuration soa, to cache the requests for which the expression $uri='^/images' evaluates to true.
tadm> create-cache-rule --condition="\$uri='^/images'" --config=soa --vs=soa.example.com cache-rule-images
OTD-70201 Command 'create-cache-rule' ran successfully.
Note that the value of the --condition option should be a regular expression. For information about building condition expressions, see "Using Variables, Expressions, and String Interpolation" in the Oracle Traffic Director Configuration Files Reference.
To change a caching rule, run the set-cache-rule-prop command.
For example, the following command disables compression of content for the caching rule cache-rule-images.
tadm> set-cache-rule-prop --config=soa --vs=soa.example.com --rule=cache-rule-images compression=false
OTD-70201 Command 'set-cache-rule-prop' ran successfully.
To delete a caching rule, run the delete-cache-rule command, as shown in the following example.
tadm> delete-cache-rule --config=soa --vs=soa.example.com cache-rule-images
OTD-70201 Command 'delete-cache-rule' ran successfully.
For the updated configuration to take effect, you should deploy it to the Oracle Traffic Director instances by using the deploy-config command.
For more information about the CLI commands mentioned in this section, see the Oracle Traffic Director Command-Line Reference or run the commands with the --help option.
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|