Applies To:

Show Versions Show Versions

Manual Chapter: Policy Management Guide for the BIG-IP WebAccelerator Module: 10 - Configuring Lifetime Rules
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>


10

Configuring Lifetime Rules


Using lifetime rules

The length of time that the WebAccelerator system keeps compiled content in its cache before refreshing it is called content lifetime. Content lifetime is expressed in the form of time to live (TTL) value and can vary for each cached response. When content is in the WebAccelerator system's cache longer than its TTL value, the WebAccelerator system considers the content expired. When the WebAccelerator system receives a request for expired content, it sends that request to the origin servers for fresh content, replaces the expired cached content with the fresh response, and then responds to the request.

You use lifetime rules to identify content lifetime options and age settings for compiled responses. The WebAccelerator system applies lifetime rules only to matching responses. Lifetime rules are not relevant to requests. The content lifetime options and age settings associated with lifetime rules are described in Configuring content lifetime settings .

Organizing lifetime rules in the Request Type Hierarchy tree

You organize lifetime rules in the Request Type Hierarchy tree, with any associated lifetime rules assigned to the leaf node. The WebAccelerator system applies lifetime rules only against leaf nodes in the Request Type Hierarchy tree. The lifetime rules defined for a leaf node are a combination of the lifetime rules and age settings defined locally at the node and any lifetime rules and age settings that are inherited from the node's ancestors. (For information about inheritance support in the Request Type Hierarchy, see Understanding hierarchy inheritance , located in Chapter 4.)

Configuring content lifetime settings

You can use lifetime rules to manage content lifetime by identifying content that you do not want the WebAccelerator system to cache, specifying content that you do not want the WebAccelerator system to serve from cache, and setting a TTL value for cached responses. All of these options are available from the Lifetime rules screen, and consist of:

  • Content lifetime options, which include directives for:
    • ESI max age
    • HTTP liftetime headers
  • Age settings, which includes options for:
    • Browser cache minimum age
    • Maximum age TTL values
    • Stand-in period
    • HTTP Lifetime Heuristic

Because you can manage cached responses by using different lifetime parameters and methods simultaneously, the WebAccelerator system obeys a precedence to manage any potential conflict. See Understanding lifetime mechanism precedence for more information.

In addition to the lifetime rule options, you can also change the system-wide TTL maximum and minimum age by editing the WebAccelerator system's configuration file. See Defining TTL boundaries for more information.

Specifying content lifetime options

You can use the following content lifetime mechanisms, when specifying options for content lifetime.

Table 10.6 Content lifetime mechanisms
Content lifetime mechanisms
Description
ESI Surrogate-Control headers
You can define control directives in the ESI Surrogate-Control response header to specify content TTL values. For more information, see Using ESI Surrogate-Control headers .
HTTP Cache-Control headers
You can use HTTP Cache-Control response header tags to define TTL values. See Using HTTP/1.1 Cache-Control Headers for more information.

 

Using ESI Surrogate-Control headers

When a site defines a page assembly with Edge Side Includes (ESI), the origin servers send ESI Surrogate-Control headers to the WebAccelerator system along with the HTTP response headers, as part of the response for requests. (See Appendix D, Assembling Content with Edge Side Includes for more information.)

When you enable the lifetime rule setting, obey ESI max age if present, the WebAccelerator system uses the max-age directive that you specify as the TTL value for compiled responses. If you do not want the WebAccelerator system to store cached ESI responses, you can use the no-store ESI Surrogate-Control header directive. For specific instructions about how to specify the ESI Surrogate-Control header directives, see Appendix B, .

Important

The max-age ESI Surrogate-Control header directive is not the same as the system-wide maximum age setting or the lifetime rules maximum age setting. You use the max-age ESI Surrogate-Control header directive to define an actual TTL for content. The system-wide maximum age setting and the lifetime rules maximum age setting is a boundary condition beyond which, for example, the max-age ESI Surrogate control directive cannot surpass.

Using HTTP/1.1 Cache-Control Headers

The HTTP version 1.1 specification identifies headers that you can use to control web entities, such as the WebAccelerator system. (For additional information, see the sections 13 and 14 of the HTTP/1.1 specification at http://www.w3.org/Protocols/rfc2616/rfc2616.html.)

HTTP Cache-Control headers can appear on requests sent by web clients and on responses sent by the origin servers. The HTTP Cache-Control general-header field specifies directives for all caching mechanisms along the request/response chain and is intended to prevent caching behavior from adversely interfering with the request or the response. Some directives can appear only in request headers, and some can appear only in response headers, and certain directives can appear in either type of header. These HTTP Cache-Control general-header field directives typically override any default caching algorithms.

Note

If the origin server return ESI Surrogate-Control headers in an HTTP response, the WebAccelerator system ignores any existing HTTP 1.1 Cache-Control headers. For example, if a response includes an ESI header with a max-age ESI Surrogate-Control header directive and an HTTP 1.1 no-cache or no-store header, the WebAccelerator system caches the response. To override this behavior, you can use a lifetime rule to prompt the WebAccelerator system to ignore the max-age ESI Surrogate-Control header directive. For additional information about ESI, see Appendix D, Assembling Content with Edge Side Includes .

When you enable the lifetime rule setting, use HTTP lifetime headers if present, the WebAccelerator system uses HTTP lifetime headers, if present, and manages content based on the associated cache directives. You can specify specific options for the HTTP Cache-Control headers, using either:

  • Cache response directives
  • Cache request directives

Specifying cache response directives

If you do not enable the lifetime rule setting, ignore no-cache HTTP headers in the response, the WebAccelerator system uses the cache response directives from the origin web server.

The cache response directives are organized in two groups:

  • no-cache
    Directives that prompt the WebAccelerator system not to cache a response.
  • max-age
    Directives that the WebAccelerator system uses to help determine the TTL value for compiled response.

no-cache

When using HTTP Cache-Control headers, the no-cache directives prompt the WebAccelerator system to send the request to the origin servers and the WebAccelerator system uses the no-cache directives to determine whether it should cache a response.

You can enable the lifetime rule setting, ignore no-cache HTTP headers in the request, to force the WebAccelerator system to ignore HTTP request no-cache headers. Doing so may result in a noticeable drop in the traffic sent to the origin server, although this is largely determined by your users' browsing habits.

The field options for the no-cache directives are described Table 10.7 .

Table 10.7 Cache response directives
Directive
Description
Pragma: no-cache
If the pragma general-header field specifies no-cache, the WebAccelerator system does not cache the response.
For information about this header field, see section 14.32 of the HTTP 1.1 specification:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.32
Cache-Control: no-cache
If Cache-Control general-header field specifies no-cache, the WebAccelerator system does not cache the response.
For information about this header field, see section 14.9.1 of the HTTP 1.1 specification:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1
Cache-Control: no-store
If Cache-Control general-header field specifies no-store, the WebAccelerator system does not cache the response.
For information about this header field, see section 14.9.2 of the HTTP 1.1 specification:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.2
Cache-Control: private
If Cache-Control general-header field specifies private, the WebAccelerator system does not cache the response.
For more information about this directive, see Section 14.9.1 of the HTTP 1.1 specification: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1

 

max-age

When using HTTP Cache-Control headers, the WebAccelerator system uses the following max-age directives to determine the TTL values for compiled responses, in the following order of priority.

For example, if the TTL values for the s-maxage and the max-age fields are different, the WebAccelerator system uses the s-maxage TTL value. The max-age directives are described in Table 10.8 .

Table 10.8 HTTP Cache-Control max-age directives
Directive
Description
Cache-Control: s-maxage
The WebAccelerator system bases the TTL on the current time, plus the value specified for the s-maxage directive. Values for this directive are expressed in seconds.
For information about the Cache-Control s-maxage directive, see section 14.9.3 of the HTTP 1.1 specification:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.3
Cache-Control: max-age
The WebAccelerator system bases the TTL on the current time, plus the value specified for the max-age directive. Values for this directive are expressed in seconds.
For information about the Cache-Control max-age directive, see section 14.9.3 of the HTTP 1.1 specification:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.3
Expires
The WebAccelerator system uses the TTL provided for this entity-header field. Values for this field are expressed in Coordinated Universal Time (UTC time).
To avoid any potential issues, it is important to ensure that that the WebAccelerator system maintains proper synchronization with the origin server, therefore, F5 Networks highly recommends that you configure a Network Time Protocol (NTP) server on the BIG-IP system.
For information about configuring NTP on the BIG-IP system, refer to the BIG-IP Network and System Management Guide, which is available on the Technical Support web site, http://tech.f5.com.
For information about the Expires entity-header field, see section 14.21 of the HTTP 1.1 specification:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.21
Last-Modified
The WebAccelerator system bases this TTL using the following formula:
TTL = curr_time + ( curr_time - last_mod_ time ) * last_mod_factor
Where:
curr_time is the time that the response is received by the WebAccelerator system
last_mod_ time is the time specified by this directive
last_mod_factor is a percentage value used to weight the TTL. It is set using the a lifetime rule.
For information about the Last-Modified entity-header field, see section 14.29 of the HTTP 1.1 specification:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.29

 

Important

The max-age HTTP Cache-Control directive is not the same as the system-wide maximum age setting or the lifetime rules maximum age setting. You use the max-age HTTP Cache-Control directive to define an actual TTL for content. The system-wide maximum age setting and the lifetime rules maximum age setting is a boundary condition beyond which, for example, the max-age HTTP Cache-Control directive cannot surpass.
Freshness calculation considerations

The HTTP 1.1 specification indicates that freshness calculations should be based on the date or age value received in the HTTP response, as defined in section 13.2.3 in the HTTP 1.1 specification: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.3

However, the WebAccelerator system assumes that the values for date and age are 0, so it bases all age calculations on the time that it receives a response from the origin server.

The extent to which this matters depends on the combination of:

  • The time delay between when a response leaves the origin server and it is received by the WebAccelerator system.
  • The difference between the UTC time set for the origin servers and the WebAccelerator system's UTC time.

In most cases, these issues are negligible, however, to ensure that the WebAccelerator system maintains proper synchronization with the origin server, F5 Networks highly recommends that you configure a Network Time Protocol (NTP) server on the BIG-IP system.

For information about configuring NTP on the BIG-IP system, refer to the BIG-IP Network and System Management Guide, which is available on the Technical Support web site, http://tech.f5.com.

Specifying cache request directives

Web clients that are HTTP version 1.1 compliant are capable of providing request headers that contain directives that control cache behavior. The WebAccelerator system obeys these directives when they indicate that the web client is unwilling to accept content served from a cache.

If the client sends an HTTP request header that prevents the WebAccelerator system from serving the content from its cache, the WebAccelerator system sends the request to the origin server. This event causes the WebAccelerator system to refresh the corresponding content that it has cached, even if that content has not yet expired.

You can enable the lifetime rule setting, ignore no-cache HTTP headers in the request, to force the WebAccelerator system to ignore HTTP response no-cache headers.

When using HTTP Cache-Control headers, the WebAccelerator system uses the cache request directives described in Table 10.9 .

Table 10.9 Cache request directives
Header
Description
Pragma: no-cache
If the Pragma general-header field includes the no-cache directive, the WebAccelerator system sends the request to the origin servers. For information about this field, see section 14.32 of the HTTP/1.1 specification:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.32
Cache-Control: no-cache
If Cache-Control specifies no-cache, then the WebAccelerator system sends the request to the origin servers. For information about this field, see section 14.9 of the HTTP/1.1 specification:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9
Cache-Control: no-store
If Cache-Control specifies no-store, the WebAccelerator system sends the request to the origin server.
Cache-Control: max-age
If the value specified on Cache-Control: max-age is less than the current age of the cached content, the WebAccelerator proxies the request.
Cache-Control: min-fresh
The WebAccelerator system proxies the request if the following is true:
curr_time + min_fresh_time > content_TTL
Where:
curr_time is the time that the request is received by the WebAccelerator system.
min_fresh_time is the time specified by this directive.
content_TTL is the time to live value set for the compiled response that corresponds to the request.

 

Defining age settings

You can use the following lifetime rules age settings to manage content lifetime:

  • Browser cache minimum age
  • Maximum age TTL values
  • Stand-in period
  • HTTP Lifetime Heuristic

Selecting browser cache options

From the Lifetime rules screen, you can select from the following browser cache options.

  • No Cache
    Do not cache content on the browser.
  • OWS
    Use the browser caching settings that are configured on the origin web server.
  • min age
    Cache content on the browser for the amount of time defined for this setting.

The browser cache minimum age (min age) setting specifies the minimum amount of time that content is stored in the web browser's local cache before the browser checks for fresh content on the WebAccelerator system. This setting affects only the browser's local cache, not the compiled response stored on the WebAccelerator system's cache, and overrides any lifetime values issued by the origin server.

Once the browser downloads content to its local cache, it uses this cached content until it reaches the browser cache minimum age value. This setting applies even if the compiled response for that content has been invalidated in the WebAccelerator system's cache (see Chapter 11, ).

By default the browser cache minimum age value is set at 0 seconds. Do not increase this value unless there is an acceptable trade off between content freshness and performance.

Most browsers update their cache with fresh content, even before this value is met, when a user clicks the browser's Refresh button. When set to a value other than 0, the browser cache minimum age also allows you to retain content off line for the specified period of time, after being fetched. This setting applies to any HTTP response that matches to a leaf node for a specific policy for which this option is set.

Important

If the Express Loader feature is enabled, then the WebAccelerator system ignores the Browser Cache Minimum Age value for any express loaded objects. The top-level HTML page uses the Browser Cache Minimum age value, if set. See Specifying advanced assembly options , located in Chapter 8, for more information.

To configure the browser cache minimum age setting

  1. On the Main tab of the navigation pane, click Policies.
    The Policies screen opens, displaying a list of acceleration policies.
  2. Click Edit next to the acceleration policy that you want to edit.
    The Policy Editor screen opens.
  3. From the Request Type Hierarchy tree, click the node for which you want to define the browser cache minimum age.
  4. On the acceleration policy menu bar, click Lifetime.
    The Lifetime rules screen opens.
  5. In the Age Settings area, click the min age option.
  6. In the min age box, type a value and select a unit of measurement (Seconds, Minutes, Hours, or Days) from the list.
  7. Click the Save button.

For a new or modified acceleration policy to be in effect for your site, you must publish it. See Publishing acceleration policies , located in Chapter 3, for more information.

Defining TTL boundaries

You can define the maximum age time to live (TTL) boundaries for cached content on the WebAccelerator system, using one of the following methods:

  • Lifetime rules
    You can configure the Maximum Age setting for an acceleration policy node, using lifetime rules. The WebAccelerator system applies any configured lifetime rules to HTTP responses that match to a specified leaf node. Once matched to a lifetime rule, that HTTP response is managed by the configured maximum age setting for that lifetime rule, regardless of any other lifetime mechanism setting.
  • System-wide TTL settings
    You can set the system-wide maximum age by editing the WebAccelerator system's configuration file. For information about changing the system-wide TTL parameters in the /config/wa/pvsystem.conf file, see Chapter 5, Changing Configuration Options, in the Administrator Guide for the BIG-IP® WebAcceleratorTM Module.

Specifying system-wide settings

The system-wide TTL settings consist of:

  • maximum age
  • minimum age

Maximum age setting

The system-wide maximum age setting, which is 24 hours, by default, overrides any other lifetime mechanisms. Therefore, the WebAccelerator system ignores lifetime mechanisms that have a TTL for compiled response set at a higher value than the system-wide maximum age.

Note

If you set the system-wide maximum age to 0, it forces the WebAccelerator system to send a GET-IF-MODIFIED request to the origin server, re-validating all content before serving it from its cache. If you want to use a maximum age of 0, make sure the system-wide minimum TTL is also set to 0.

Minimum age setting

The default for the system-wide minimum TTL value is 2 seconds. If you set the maximum age for an acceleration policy with a value less than the system-wide minimum TTL value, the WebAccelerator system will use the system-wide minimum TTL setting, instead of the system-wide maximum TTL value.

Specifying the stand-in period

The stand-in period identifies how long the WebAccelerator system continues to serve content from its cache, if the origin server does not respond to the WebAccelerator system's requests for fresh content.

If the WebAccelerator system still cannot retrieve fresh content from the origin server after the stand-in period expires, it responds to subsequent requests for that content with an HTTP 404 (not found) response code.

The default stand-in period is 0. If you do not specify a stand-in period, the WebAccelerator system immediately responds with an HTTP 404 (not found) response code if content expires and the WebAccelerator system cannot obtain fresh content from the origin servers.

To specify a value for the stand-in period

  1. On the Main tab of the navigation pane, click Policies.
    The Policies screen opens, displaying a list of acceleration policies.
  2. Click Edit next to the acceleration policy that you want to edit.
    The Policy Editor screen opens.
  3. From the Request Type Hierarchy tree, click the node for which you want to define stand-in period.
  4. On the acceleration policy menu bar, click Lifetime.
    The Lifetime rules screen opens.
  5. In Age Settings area, type a value in the box next to Stand-in Period and select a measurement of time from the adjacent list.
  6. Click the Save button.

For a new or modified acceleration policy to be in effect for your site, you must publish it. See Publishing acceleration policies , located in Chapter 3, for more information.

Note

You can also specify a stand-in period using the max-age directive in an ESI Surrogate-Control response header. See Using ESI Surrogate-Control headers for details.

Calculating the HTTP Lifetime Heuristic

To determine the HTTP Lifetime Heuristic, the WebAccelerator system reviews the value for the HTTP LAST_MODIFIED response header and computes the cache expiration based as a percentage of the number of days since it was modified. For example, if the HTTP LAST_MODIFIED response header specifies that an object was last modified 30 days ago and the heuristic is set to 50%, the WebAccelerator system caches the object for 15 days.

The HTTP Lifetime Heuristic is only in effect if you are using HTTP headers to identify content lifetime. Use this setting only if you want to use the HTTP LAST_MODIFIED response header to set compiled response TTL values.

To specify a value for the HTTP Lifetime Heuristic

  1. On the Main tab of the navigation pane, click Policies.
    The Policies screen opens, displaying a list of acceleration policies.
  2. Click Edit next to the acceleration policy that you want to edit.
    The Policy Editor screen opens.
  3. From the Request Type Hierarchy tree, click the node for which you want to define the HTTP Lifetime Heuristic setting.
  4. On the acceleration policy menu bar, click Lifetime.
    The Lifetime rules screen opens.
  5. In the box next to HTTP Lifetime Heuristic, type a percentage value.
  6. Click the Save button.

For a new or modified acceleration policy to be in effect for your site, you must publish it. See Publishing acceleration policies , located in Chapter 3, for more information.

Understanding lifetime mechanism precedence

The WebAccelerator system determines the TTL for a compiled response by observing the following:

  • System-wide age settings.
  • Content lifetime values.
  • Age information supplied when using ESI or HTTP.

If one or more values for these mechanisms conflict, the WebAccelerator system uses the following precedence:

  • The TTL values for compiled response cannot be greater than the system-defined maximum lifetime values and cannot be shorter than the system-defined minimum lifetime values. See Specifying content lifetime options for more information.
  • If a maximum age setting is defined for a lifetime rule, you cannot configure a lifetime mechanism with a TTL value greater than the value for the maximum age setting.
  • If you are using ESI headers, the TTL value indicated by the ESI Surrogate-Control header's max-age directive supersedes all other TTL values, provided that the ESI max-age value does not violate the boundary conditions described in the previous two bullets.
  • The WebAccelerator system uses HTTP lifetime headers only if the ESI max-age directive is not used, or is otherwise not available. To use HTTP lifetime headers, you must create a lifetime rule with HTTP lifetime headers enabled.
  • If the lifetime rule indicates that the WebAccelerator system should not use a lifetime mechanism, or if HTTP lifetime headers are not otherwise available, then the WebAccelerator system uses the TTL value specified for the lifetime rule's maximum age setting.
  • If there is no lifetime mechanism configured, and you have not specified a maximum age value for the acceleration policy, the WebAccelerator uses the system-defined maximum lifetime value for the content lifetime TTL value.

Configuring a lifetime rule example

This section of the chapter provides information about how to configure an example lifetime rule. For this example site, you have three top-level nodes in the Request Type Hierarchy as follows:

  • Home
    Specifies the rules related to the home page.
  • Applications
    Specifies the rules related to the applications for the site, with child nodes, such as:
    • Default
      Specifies the rules related to non-search related applications.
    • Search
      Specifies the rules related to your site's search application.
  • Images
    Specifies the rules related to graphics images.
Note

See, To create the Home, Application, and Images nodes for the example Request Type Hierarchy tree , located in Chapter 4, for specific instructions about how to create the Request Type Hierarchy tree.

For this example:

  • Your home page and your image files very rarely change, therefore, you use the WebAccelerator system to cache the home page and images in accordance with its default settings. If you make a change to the home page, you use some form of content invalidation to force a refresh for the new content. See Chapter 11, for more information on content invalidation.
  • The content that your general applications serve changes about once every 4 hours. You use some form of content invalidation to force a refresh when content changes, but you do not want this content to remain in the WebAccelerator system's cache for more than 5 hours without a refresh. To ensure that you can manage content invalidation, you do not want to rely solely on the browser's local cache settings, so you do not have a minimum time set for content residing in the browser cache before freshness checks.
  • Your search application returns data that has varying expiration times, some expires in as short a time as 10 minutes and some of it expires at 8 hours. You intend to use the HTTP Expires Cache-Control header to identify the cache time for content served by the search application.
  • Finally, you change site content approximately every 4 hours, so you are willing to allow the WebAccelerator system to serve content that 8 hours, (or twice that) old if the origin servers are not responding to the WebAccelerator system's refresh requests. For the search applications that change more frequently, you want the stand-in period to be 2 hours longer than the cache TTL.

For this example, you configure the lifetime rules for the Request Type Hierarchy tree nodes as described in Table 10.10

Table 10.10 Node settings for Request Type Hierarchy tree example
Node
Application Matching Parameter
Home
Create a lifetime rule with a stand-in period of 8 hours, and a maximum lifetime of 24 hours. Provide no other settings for the acceleration policy, so the home page is cached for the maximum amount of time allowed by the WebAccelerator system.
Image
Create a lifetime rule with a stand-in period of 8 hours, and a maximum lifetime of 24 hours. Provide no other settings for the acceleration policy, so the images page is cached for the maximum amount of time allowed by the WebAccelerator system.
Default
Create a lifetime rule with a maximum cache time of 5 hours and a stand-in period of 8 hours.
Search
Create a lifetime rule with HTTP headers support enabled for the lifetime mechanism. Also, set a maximum cache time of 8 hours and a stand-in period of 10 hours.

 

The following procedures describe how to create the lifetime rules for the Default and Search nodes. Follow the same procedure to create the lifetime rules for the Home and Image nodes.

To create the example Default node's lifetime rule

  1. On the Main tab of the navigation pane, click Policies.
    The Policies screen opens, displaying a list of acceleration policies.
  2. Click Edit next to the acceleration policy that you want to edit.
    The Policy Editor screen opens.
  3. From the Request Type Hierarchy tree, click the Default node.
  4. On the acceleration policy menu bar, click Lifetime.
    The Lifetime rules screen opens.
  5. Clear the Obey ESI max age if present check box.
  6. Clear the Use HTTP lifetime headers if present check box.
  7. In the Age Settings area:
    1. Click the min age setting, type 0 in the box, and select Seconds from the list.
    2. For Maximum Age, type 5 in the box and select Hours from the list.
    3. For Stand-in Period, type 8 in the box and select Hours from the list.
  8. Click the Save button.

To create the example Search node's lifetime rule

  1. From the Request Type Hierarchy tree, click the Search node.
  2. On the acceleration policy menu bar, click Lifetime.
  3. Clear the check box for Obey ESI max age if present.
  4. Clear the check boxes for Ignore no-cache HTTP headers in the request and Ignore no-cache HTTP headers in the response.
  5. In the Age Settings area:
    1. Click the min age option, type 0 in the box, and select Seconds from the list.
    2. For Maximum Age, type 8 in the box and select Hours from the list.
    3. For Stand-in Period, type 10 in the box and select Hours from the list.
  6. Click the Save button.

For a new or modified acceleration policy to be in effect for your site, you must publish it. See Publishing acceleration policies , located in Chapter 3, for more information.




Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)