Applies To:

Show Versions Show Versions

Manual Chapter: Changing Default Settings
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

4
Before sending a response to a client, the WebAccelerator system enters an informational X-PvInfo response header into the response to describe how it handled the response. You cannot change these informational headers, and they do not affect processing, however, they can provide useful information for evaluating the efficiency of your acceleration policies.
Part of the information included in the X-PvInfo response header is the object type. The WebAccelerator system classifies, by object type and group, every response it receives from the origin web servers. The object type and group classification determine how the WebAccelerator system handles compression for the response.
To classify a response by object type, the WebAccelerator system reviews the response headers and classifies the responses based on the first information it finds, in the following order:
File extension in the Content-Disposition headers file name field
File extension in the Content-Disposition headers extension field
Content-Type header in the response, unless it is an ambiguous MIME type
For example, if the extension in the Content-Disposition headers file name field is empty, then the WebAccelerator system looks at the Content-Disposition headers extension field. If Content-Disposition headers field has an extension, the WebAccelerator system checks to see if an object type is configured for the extension. If there is no match, it assigns an object type of other, and uses the object settings for other. The WebAccelerator system looks at the information in the Content-Type header only if there is no extension in the Content-Disposition headers file name or extension fields.
In addition to classifying the response by object type, the WebAccelerator system also classifies the response by group. For example, in the following X-PvInfo response header the object type (OT) is defined as Microsoft Word (msword) and the object group (OG) is documents.
Note: For information about the other content contained in a X-PvInfo response header, see the Policy Management Guide for the BIG-IP® WebAccelerator System.
Pre-defined Object Types
The WebAccelerator system ships with several predefined object types, most of which are optimized for objects associated with specific applications.
User-defined Object Types
A user-defined object type is an object type that you create and for which you specify all of the parameters dictating how the WebAccelerator system manages the specified object type.
The Objects Types screen displays all of the object types that the WebAccelerator system is currently applying to your acceleration policies.
In the navigation pane, expand WebAccelerator, click Policies, then click Object Types.
Figure 4.1 shows an example Object Types screen.
From the Object Types screen, you can view the object types that the WebAccelerator system is currently applying to acceleration policies, as well as access additional screens where you can perform the following tasks:
When you create a new object type or modify an existing object type, the WebAccelerator system applies the object type changes globally to all acceleration policies. If you have an optional symmetrical deployment, new objects types that you create and changes that you make to existing objects synchronize with the other WebAccelerator systems in the symmetrical deployment.
1.
In the navigation pane, expand WebAccelerator, click Policies, and then click Object Types.
The Policies, Object Types screen displays a list of user-defined and predefined object types.
2.
Click the Create button.
The Policies, Object Types, New Object Type screen displays settings for a new object type.
3.
In the Description box, type a descriptive name to display on the Object Types screen for the new object. For example, Rich Text Format.
4.
In the Object Type box, type a short name for the new object. For example, rtf. This name displays on the Object Types screen and in the X-PvInfo response header.
5.
From the Group list, select a group that you want to display in the X-PvInfo response header for the new object.
Alternatively, select Add a new group, and type a new group name in the box.
6.
For each extension you want to add for the new object, click the Add button and type the extension, as a single value, into the box. For example, rtx.
Note: Do not include a preceding period ( . ) when specifying an extension.
When the WebAccelerator system finds a file extension in a file name or in the Content-Disposition header of the response, it attempts to match that extension to one of the values that you specified. If there is a match, it classifies the response as the object you specified for the extension.
7.
For each MIME type you want to add for the new object, click the Add button and type the MIME type, as a single value, into the box. For example, application/rtf.
If the WebAccelerator systems does not find an extension in the name or extension fields of the Content-Disposition header, it looks in the Content-Type header of the response to attempt to match that to one of the MIME types you specified. If there is a match, it classifies the response as the object you specified for the MIME type.
8.
From the Enable Compression list, select one of the following to specify when the WebAccelerator system should use gzip in the response:
Policy Controlled
Uses the compression setting specified in the assembly rule, which the WebAccelerator system matched for this object type. This is the default setting.
In Symmetric Deployment only
Compresses the response only if the client is another WebAccelerator system in a symmetric deployment.
Keep in mind that if you select this option, it supersedes the assembly rules Enable Content Compression setting for this object type. Select this option only if you have a symmetric deployment and want the WebAccelerator system to compress this object type when it is sent between a central and remote WebAccelerator system.
None
Never compresses the response.
Keep in mind that if you select this option, it overrides the assembly rules Enable Content Compression setting for this object type. Select this option only if you want the WebAccelerator system to ignore the compression setting for any configured assembly rules that matches to the specified object type.
9.
Click Save.
The screen refreshes and the new object type that you created displays in the User-defined Object Types table and the WebAccelerator system applies the new object type to all acceleration policies.
1.
In the navigation pane, expand WebAccelerator, click Policies, and then click Object Types.
The Policies, Object Types screen displays a list of user-defined and predefined object types.
3.
Edit the object type parameters as required.
For specific information about each setting, see the online help.
4.
Click Save.
The WebAccelerator system applies object type changes to all acceleration policies.
To return to the Object Types screen without saving the object, click the Cancel button.
When you modify a predefined object type and save it, an information icon displays next to the display name in the predefined object types table, indicating that the parameters for the object type are modified from the original version that was shipped with the WebAccelerator system.
1.
In the navigation pane, expand WebAccelerator, click Policies, and then click Object Types.
The Policies, Object Types screen displays a list of user-defined and predefined object types.
3.
Click the Delete button again to confirm the deletion, keeping in mind that you cannot recover a deleted object type.
The screen refreshes and the object type that you deleted no longer displays in the User-defined Object Types table.
To return to the Object Types screen without deleting the object, click the Cancel button.
Warning: When you use the following commands, the WebAccelerator system resets all object type options to the default settings. All customized settings, including normalization settings and user-defined object types you may have created, are lost.
When the WebAccelerator system receives a response, it analyzes the contents of the response and creates an object ID based on the specific content. To recognize content independent of its URL, the WebAccelerator system inserts the object ID it created into the response that it returns to the client. This process is called URL normalization. The normalized objects are stored in a separate application called Normalization.
Another component of the URL normalization process is the option to send the normalized URL to the requesters browser. When the URL Normalization to Browser setting is enabled, the WebAccelerator system sends the normalized URL in the form of a redirect to the client browser, so that the browser can search its own cache for a copy of the content based on the requests URL. If the browser finds the content in its own cache, the WebAccelerator system does not have to send the response again, which reduces bandwidth usage and speeds up the response time to the client.
Performs URL normalization only for responses that contain objects that are classified in a documents group. (A documents group consists of objects or files that are 20KB or larger in size, and contain Microsoft® Word®, Microsoft® Excel®, and Microsoft® PowerPoint® objects, or Adobe® PDF files.)
Has the virtual base path, where the normalized objects appear to come from, set to /pv_obj_cache.
It is important that you are aware of the associated restrictions and security considerations when the URL Normalization to Browser setting is enabled.
If your web site contains frame sets embedded using JavaScript, it is possible that the redirects to a browser will fail. Although this is not typically an issue if you specify documents as the only object group, it can occur.
Warning: If you enable URL normalization, you should also set the Required Authorization setting to Yes to prevent the risk that a client might use the normalized URL to access secure content.
You can define whether the WebAccelerator system performs URL normalization and whether it uses a redirect to send the normalized content to browsers. You can also specify the type of content on which you want the WebAccelerator system to perform URL normalization.
1.
In the navigation pane, expand WebAccelerator, click Policies, and then click URL Normalization.
The Policies, URL Normalization screen displays settings to normalize content.
2.
Modify the settings, as required.
For specific information about each setting, see the online help.
3.
Click Save, or click Cancel to revert to the previous settings.
If you do not want the WebAccelerator system to normalize certain URLs, you can selectively disable the content-based identity feature associated with a certain document type (node) for a specific user-defined acceleration policy. The WebAccelerator system does not normalize redirects for any requests or responses that match to a node that has content-based identity disabled, and it does not perform content-based cache routines for those nodes.
You disable content-based identity and normalization for a specific node in a user-defined acceleration policy, using an assembly rules advanced assembly options.
Important: You can disable the content-based identity for specific nodes only if the URL Normalization option is set to Enable. This setting is global; therefore, if the URL Normalization option is set to Disable, the WebAccelerator system does not perform URL normalization on any URLs.
1.
In the navigation pane, expand WebAccelerator, and click Policies.
The Policies screen displays a list of existing acceleration policies.
4.
From the Matching Rules list on the Policy Editor menu bar, select Acceleration Rules.
6.
From the Content Assembly Options list, select Advanced.
The screen refreshes to display additional options.
7.
In the Advanced Assembly box, type:
8.
Click Save.
For a new or modified acceleration policy to be in effect for your site, you must publish it. One way to do this is to click the Publish button from any screen within the Policy Editor to open the Publish screen.
After you install and configure the WebAccelerator system, you can customize the system for your site by changing the default settings for the following options:
To modify these settings, you edit the /config/wa/pvsystem.conf file.
Important: Before you make changes to the /config/wa/pvsystem.conf file, we recommend that you first create a backup copy using the
cp /config/wa/pvsystem.conf/config/wa/pvsystem.conf.back command. This enables you to easily restore the modified configuration in case of a system failure.
2.
Edit the /config/wa/pvsystem.conf file as required.
The parameters for these options are specified on the following pages.
The WebAccelerator system generates information about page requests in log files called change logs, and information similar to web server log files in hit logs. By default, the WebAccelerator system buffers the change log and hit log information in memory until it reaches a size of 10 MB, at which time it writes the information to the hard drive (rotates).
The threshold for the data in the hit and change logs is based on content size and Time-to-Live (TTL) value. The WebAccelerator system resets the TTL values each time it writes the change log or hit log to disk. For example, by default, if the WebAccelerator system writes a change log at 3 minutes because a file size reached the limit, it resets the TTL counter to 0 and does not write the change log again until either 5 minutes have elapsed, or it has collected 1MB of data, whichever comes first.
Warning: The default values for the size and TTL threshold limits work well for most configurations, and you should not change them unless instructed to do so by an F5 Network Technical Support Engineer.
If you are instructed to change the size or TTL threshold values for hit or change logs, you can modify the /config/wa/pvsystem.conf file parameters described in Table 4.1. After you change a parameter, save the file and then restart the process using the bigstart restart pvac command.
Maximum amount of change log data allowed buffered in memory before the WebAccelerator system writes change log data to disk.
Default is 1000000 (1MB).
Maximum amount of hit log data allowed buffered in memory before the WebAccelerator system writes change log data to disk.
Default is 1000000 (1MB).
Interval at which the WebAccelerator system writes change log data to disk, regardless of how much change log data is buffered in memory.
Default is 5 minutes.
Interval at which the WebAccelerator system writes hit log data to disk, regardless of how much hit log data is buffered in memory.
Default is 5 minutes.
The WebAccelerator system assigns a Time-to-Live (TTL) value to every compiled response that it caches. The TTL value defines the time that is allowed to elapse before the compiled response expires and the WebAccelerator system sends a request to the origin web server for fresh content. This length of time is called the content lifetime, and can vary for each compiled response.
For most compiled responses, you can define the content lifetime using acceleration policies. (See the Policy Management Guide for the BIG-IP® WebAccelerator System for more information.) Another option is to adjust the TTL values using the various lifetime mechanisms available in the HTTP and ESI protocols. However, in either case you cannot set TTL values to exceed the system limits that are controlled with the parameters that are defined in the /config/wa/pvsystem.conf file.
If you determine that you need to change the system limit TTL values for compiled responses, you can modify the /config/wa/pvsystem.conf file parameters described in Table 4.2. After you change a parameter, save the file and then restart the process using the bigstart restart pvac command.
Table 4.2 TTL parameters
The system-wide maximum TTL value.
Default is 86400 seconds (24 hours).
A system-wide default value for the HTTP last mod factor. The WebAccelerator system uses this value in an equation that determines TTL values based on information found in HTTP headers. You can use acceleration policies to override this default value.
Note: Content lifetime and TTL values are described in further detail in the Policy Management Guide for the BIG-IP® WebAccelerator System.
The WebAccelerator system is capable of encrypting cookies that it sets on a client. When the client presents the cookie back to the WebAccelerator system, the WebAccelerator system decrypts it and processes it. Further, if the WebAccelerator system must send a request to the origin web servers, it decrypts the cookie before it sends a response to the client.
By using encrypted cookies, you ensure that the client cannot examine the information contained in the cookie. This can prevent malicious users from examining the contents of your cookies and gaining knowledge about how your site works.
If you determine that you need to change the default settings for cookie encryption, you can modify the /config/wa/pvsystem.conf file parameters described in Table 4.3. After you change a parameter, save the file and then restart the process using the bigstart restart pvac command.
When this parameter is set to true, the WebAccelerator system encrypts cookie names.
When this parameter is set to true, the WebAccelerator system encrypts cookie values.
When this parameter is set to true, the WebAccelerator system examines the IP address of the client presenting the cookie before decrypting the cookie.
Using this feature can reduce performance slightly, however, it ensures that the WebAccelerator system decrypts a cookie only if it is presented by the client to which the cookie was originally set.
When this parameter is used, the WebAccelerator system only encrypts cookies with a name that matches the provided regular expression. You must include the start of line (^) and end of line ($) expressions. For example, to encrypt all cookies that begin with myDomain, use:
The WebAccelerator system uses a shell script called hds_prune to clear any compiled responses that are no longer needed from the WebAccelerator systems on-disk cache.
The script works by periodically checking the current capacity of the on-disk cache. If the amount of available free space for the on-disk cache is less than or equal to the minimum amount specified by the hdsPruneStartLevel parameter, the script prunes the cache. When pruning, the script removes enough data from the on-disk cache to satisfy the maximum amount specified by the hdsPruneStopLevel parameter. That is, when the script is done, the amount of free space in the on-disk cache partition is as big as the maximum specified by the hdsPruneStopLevel parameter.
If you determine that you need to change the default settings for the hds_prune script, you can modify the /config/wa/pvsystem.conf file parameters described in Table 4.4. After you change a parameter, save the file and then restart the process using the bigstart restart pvac command.
The length of time that passes before the script starts checking the current amount of free space available in the on-disk cache partition.
Default is 300 seconds (5 minutes).
The smallest amount of free space allowed in the on-disk cache partition. If hds_prune finds that the on-disk cache partition has a free space value that is less than or equal to this value, then it prunes the on-disk cache. Values are expressed as a percentage of free space.
The default is to start pruning when there is less than 20% of the disk free.
The amount of free space that must be available in the partition when hds_prune is finished pruning the on-disk cache. Values are expressed as a percentage of free space.
The default is to stop pruning when there is at least 40% of the disk free.
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)