Applies To:

Show Versions Show Versions

Manual Chapter: Policy Management Guide for the BIG-IP WebAccelerator Module: 4 - Introducing the Request Type Hierarchy Tree
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>


4

Introducing the Request Type Hierarchy Tree


Overview of the Request Type Hierarchy tree

You organize all of the acceleration policies that you have defined for your application in the Request Type Hierarchy tree. Each node on the Request Type Hierarchy tree represents matching rules and caching rules. For each incoming HTTP request, the WebAccelerator system uses the matching rules to find the best leaf node to match (as described in Understanding matching rules , located in Chapter 2) and then applies the corresponding caching rules. In the event that a request matches two nodes equally, the WebAccelerator system matches to the node with the highest priority in the Request Type Hierarchy tree.

To view the Request Type Hierarchy tree for a user-defined acceleration policy

  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 an acceleration policy.
    The Policy Editor screen opens and the Request Type Hierarchy tree displays to the left of the screen. By default, the nodes are displayed in order of priority.
  3. To view the nodes in alphabetic order, select Alphabetical from the View list.

Figure 4.4 shows an example of the Request Type Hierarchy tree.

 

 

Figure 4.4 Request Type Hierarchy tree example

In this example, the Application node defines the caching rules, which are inherited by the Default and Search leaf nodes. This is illustrated by the fact that the Default and Search leaf nodes are a subset of the Application node.

Understanding hierarchy inheritance

Nodes are used for inheritance only. The WebAccelerator system performs application matching only against the leaf (child) nodes in the Request Type Hierarchy tree. This means that the WebAccelerator system does not apply matching and caching rules that are associated with a node directly to an HTTP request. Rather, nodes provide a simple way for you to propagate matching and caching rules across one or more leaf nodes.

For example, to create several leaf nodes with different matching rules and a similar caching variation rule, you can create the leaf nodes under one node and specify the matching rule as the parent. Since a leaf node inherits the rules from its parent, you can create multiple acceleration policies with the same rules faster and more consistently than creating the same acceleration policy repeatedly, for different leaf nodes.

You can create matching and caching rules by:

  • Local definition
    Creates a rule at the node level and does not inherit options from its ancestor.
  • Inheritance
    Creates a rule at the node level, and then creates a leaf that inherits the rules from the node (ancestor).
  • Inheritance and overrides combination
    Creates a rule at the node level and then creates a leaf that inherits the rules from the node (ancestor), but overrides some of the rule options at the leaf node.

Inheriting from a leaf node on the Request Hierarchy tree

In each rule, there are icons that indicate inheritance status for a particular rule parameter. For example, in Figure 4.5 there are two parameters for a rule.

 

Figure 4.5 Leaf node inheritance example

The arrow icon below Path indicates that the Path parameter is inherited while the parameter for Header does not have an arrow, indicating that it is not inherited. Since the Header parameter is not inherited, you can delete it at the leaf node level by clicking Delete. However, you cannot delete the Path parameter because it was inherited from an ancestor node. To delete the Path parameter, you must delete it at the node level.

If you decide to create a user-defined acceleration policy, you must know from which Request Type Hierarchy tree leaf node the acceleration policy is inheriting its rules and decide whether you want to change the rules on the leaf node or change the rules on an ancestor leaf node.

To view the node from which the Path option was inherited, click the arrow icon next to Path. The inheritance setting window opens, displaying the ancestor's node name.

Overriding inherited rules

It is important that you set up your leaf nodes in a logical way. You should only specify rules for ancestor leaf nodes that you want most of the leaf nodes to inherit. Do not set a rule at a leaf node if you know that most of the leaf nodes will not use this rule. When editing an inherited rule, you can change a parameter value and any associated options. The changes you make override the inherited settings for the specified parameter.

You can override rules at any level in the Request Type Hierarchy tree. The WebAccelerator system propagates all overrides to the leaf nodes, along with any new rules that you defined for the node. When overriding rules, you always have the option of reverting to the original inherited definition.

When a leaf node inherits rules from a node, it inherits all of the rule options from the parent node. If you change an inherited rule at the leaf node level, the inherited rule is overridden.

For example, for the content assembly rule in Figure 4.6 , all of the options are inherited, except for the Compress contents option, which is overridden at the current node as indicated by the red X icon next to Compress contents. This means that when you copied this node, you used all of the rule options from the node, except for Compress contents.

 

 

Figure 4.6 Child leaf node example

The override icon displays only for the options that the current node overrides. You cannot see if a parent node inherited the rule and overrode an option that the node inherited. To see if the current node inherited an option that was overridden, click the parent node and view its rules. For example, the parent leaf node may appear as shown in Figure 4.7 .

 

 

Figure 4.7 Parent of leaf node example

In this instance, the node overrides no rules, which means the rules were inherited at the grandparent leaf node. To confirm this, view the grandparent's leaf node, which appears as follows.

 

 

Figure 4.8 Grandparent of leaf node example

By following the inheritance, we see that all the rule options are actually set at the grandparent's leaf node. They are not inherited from any other node, and they are all enabled.

If, for example, you want to enable the Express Loader at the original leaf node, you can use one of the following options:

  • Override the inherited setting at the leaf node and check the box.
  • Cancel the override setting at the parent, so that the parent inherits the Express Loader enabled option of the grandparent, and in turn passes that setting to the leaf node.

If you cancel the override setting at the grandparent leaf node, keep in mind that this action changes the settings for all the child leaf nodes, not just the leaf node you want to change.

Modifying nodes in the Request Type Hierarchy tree

You create a user-defined acceleration policy by copying a pre-defined acceleration policy and editing it from the Policy Editor screen. You can customize the copy of the acceleration policy that you created by modifying the nodes in the Request Type Hierarchy tree, as required.

Important

You can edit only acceleration policies that you copy or create. You cannot edit pre-defined application policies.

To modify nodes, you use the following Request Type Hierarchy menu options, located above the Request Type Hierarchy tree.

  • Add
    Use this option to add a new node.
  • Edit
    Use this option to edit a node's name and description.
  • Delete
    Use this option to delete a node.
  • Copy
    Use this option to copy a node.
  • Up, Down
    Use this option (available only when nodes are displayed by priority) to change a node's priority. Note that you can change a priority only within a branch of the tree.
Note

You can change a priority only within a branch of the tree. For example, in Figure 4.4 , you can give the Default leaf node priority over the Search leaf node, but not over the Images node.

To add a new leaf node to the Request Type Hierarchy tree

  1. From the Request Type Hierarchy tree, click the node to which you want to add a leaf node.
  2. From the Request Type Hierarchy menu options, click Add.
    The Add a Node popup screen opens.
  3. In the Name box, type a name for the new leaf node.
  4. In the Description box, type an optional description.
  5. Click the Create Node button.
    The screen refreshes and the new node displays in the Request Type Hierarchy tree. The new leaf node inherits all of the rules from its parent node.

To edit a node on the Request Type Hierarchy tree

  1. From the Request Type Hierarchy tree, click the node that you want to edit.
  2. From the Request Type Hierarchy menu options, click Edit.
    The Edit a Node popup screen opens.
  3. Edit the name and description of the node, as required.
  4. Click the Save button.
    The screen refreshes and node displays in the Request Type Hierarchy tree with the changes you made.

To delete a node on the Request Type Hierarchy tree

  1. From the Request Type Hierarchy tree, click the node that you want to delete.
  2. From the Request Type Hierarchy menu options, click Delete.
    The Remove a Node popup screen opens.
  3. Click the Delete button.
    The node is removed from the Request Type Hierarchy tree.

To copy a node on the Request Type Hierarchy tree

  1. From the Request Type Hierarchy tree, click the node that you want to copy.
  2. From the Request Type Hierarchy menu options, click Copy.
    The Copy a Node screen opens.
  3. In the Name box, type a name for the new node.
  4. In the Description box, type an optional description.
  5. Click the Create Node button.
    The screen refreshes and the new node displays in the Request Type Hierarchy tree.

To change the priority of a node on the Request Type Hierarchy tree

  1. From the Request Type Hierarchy tree, click the node for which you want to change the priority.
  2. From the Request Type Hierarchy menu options, click Up or Down.
    The node changes positions in the Request Type Hierarchy tree, as directed.

Configuring a Request Type Hierarchy tree example

This section of the chapter provides information about how to configure an example Request Type Hierarchy tree. For this example site, you receive four basic types of requests. The request types and the associated URLs are as follows.

  • Requests for the home page. For example:
    http://www.siterequest.com/
    http://www.siterequest.com/index.jsp
  • Requests for non-graphic content. For example:
    http://www.siterequest.com/apps/doSomething.jsp
    http://www.siterequest.com/apps/doSomethingElse.jsp
    http://www.siterequest.com/apps/doAnotherThing.jsp
  • Requests for search applications. For example:
    http://www.siterequest.com/srch/doSearch.jsp
    http://www.siterequest.com/srch/doSimpleSearch.jsp
  • Requests for graphics images. For example:
    http://www.siterequest.com/images/<someimage>.gif

For the site in this example, you create a Request Type Hierarchy tree with the following three top-level nodes. The names of the nodes are arbitrary.

  • Home
    Specifies the rules related to the home page.
  • Applications
    Specifies the rules related to the applications for the site, with leaf 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.

To create the example user-defined acceleration policy

  1. On the Main tab of the navigation pane, expand WebAccelerator, and click Policies.
    The Policies screen opens with a list of acceleration policies.
  2. Click the New Policy button at the bottom of the screen.
    The New Policy screen opens.
  3. In the Name box, type a name for the new acceleration policy.
  4. In the Description box, type an optional description.
  5. Click the Create button.
    The Policies screen refreshes with the new acceleration policy that you created.
  6. Click Edit next to the acceleration policy that you created.
    The Policy Editor screen opens in Edit Development (Not Published) mode.

To create the Home, Application, and Images nodes for the example Request Type Hierarchy tree

  1. From the Request Type Hierarchy menu options, click Add.
    The Add a Node popup screen opens.
  2. In the Name box, type a name for the new node.
    For this example, Home.
  3. In the Description box, type an optional description.
  4. Check the box next to Create a new tree in the hierarchy to create a new node.
  5. Click the Create Node button.
    The Request Type Hierarchy tree refreshes, displaying the new Home node.
  6. Repeat steps 1 through 5 for the Application and Images nodes.

To create the Default and Search leaf nodes for the example Request Type Hierarchy tree

  1. From the Request Type Hierarchy tree, click the Applications node.
  2. From the Request Type Hierarchy menu options, click Add.
    The Add a Node popup screen opens.
  3. In the Name box, type a name for the new node.
    For this example, Default.
  4. In the Description box, type an optional description.
  5. Click the Create Node button.
    The Request Type Hierarchy tree refreshes, displaying the new leaf node.
  6. Repeat steps 1 through 5 to create the Search leaf node.
    The Request Type Hierarchy tree refreshes, displaying the new leaf node.

The completed Request Type Hierarchy tree should now appear as shown in the Figure 4.9 .

 

 

Figure 4.9 Example Request Type Hierarchy tree

To define matching rules for this Request Type Hierarchy tree, see Chapter 6, .

For information about specifying caching rules for each node, see:




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)