Applies To:

Show Versions Show Versions

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

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 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, every response it receives from the origin web servers. To do this, 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 file extension in 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 currently configured for the extension. If there is no match, the WebAccelerator system assigns an object type of other, and uses the 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.
Consider the following X-PvInfo response header:
In this example, the object type (OT) is defined as Microsoft Word (msword) and the object group (OG) is documents.
Note: For more 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 pre-defined 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 specfied object type.
The Objects Types screen displays all of the object types that the WebAccelerator system is currently applying to your acceleration policies. 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. The WebAccelerator system stores the settings for the object types in the globalfragment.xml file.
1.
On the Main tab of the navigation pane, expand WebAccelerator, and click Policies.
The Policies screen opens.
2.
From the navigation pane, click Object Types.
The Object Types screen opens, displaying the existing object types.
3.
Click the Create button, located above the table.
The New Object Type screen opens.
4.
In the Description box, type a descriptive name to display on the Object Types screen for the new object. For example, Rich Text Format.
5.
In the Object Type box, type a short name to identify the new object to display on the Object Types screen and in the X-PvInfo response header. For example, rtf.
6.
From the Group list, select a group 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.
7.
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.
8.
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.
9.
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.
10.
Click the Save button to save your changes.
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.
To return to the Object Types screen without saving the object, click the Cancel button.
1.
On the Main tab of the navigation pane, expand WebAccelerator, and click Object Types.
The Object Types screen opens, displaying the existing pre-defined and user-defined object types.
2.
3.
Edit the object type parameters as required.
For specific information about each setting, see the online help.
4.
Click the Save button to save your changes.
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.
Note: When you modify a pre-defined object type and save it, an information icon displays next to the display name in the pre-defined 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.
On the Main tab of the navigation pane, expand WebAccelerator, click Object Types.
The Object Types screen opens, displaying the existing object types.
2.
Check the box next to the display name of the user-defined object that you want to delete, and then click the Delete button.
The Delete Object Type Confirmation screen opens.
3.
Click the Delete button 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 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 view and modify the URL normalization settings from the Edit URL Normalization Settings screen, illustrated in Figure 4.2.
From the Edit Normalization Settings screen, 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.
Important: When you make modifications to URL normalization settings, the WebAccelerator system applies those changes globally, to all acceleration policies.
1.
2.
Click URL Normalization.
The Edit URL Normalization Settings screen opens.
3.
Modify the settings, as required.
For specific information about each setting, see the online help.
4.
Click the Save button to save any changes you made.
The WebAccelerator system applies globally, to all acceleration policies, any modifications that you made to the URL normalization settings.
Click the Cancel button to revert back to the previous URL normalization 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 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.
On the Main tab of the navigation pane, expand WebAccelerator, and then click Policies.
The Policies screen opens displaying existing acceleration policies.
2.
From the User-defined Acceleration policy table, click the name of the acceleration policy that you want to modify.
4.
From the Matching Rules list on the Policy Editor menu bar, select Acceleration Rules.
The acceleration rules display on the Policy Editor menu bar.
5.
On the Policy Editor menu bar, click Assembly.
The Assembly rule screen opens.
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 the Save button.
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. We recommend that if you are making a series of changes to an acceleration policy, click the Publish button on the Policy Editor screen only after you make the last change in the series.
Once you have installed and configured 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. The WebAccelerator system buffers the change log and hit log information in memory until a specified threshold is reached, at which time the WebAccelerator system writes the information to the hard drive.
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, in accordance with the default settings, 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.
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.
The WebAccelerator system writes change log data to disk if the amount of change log data buffered in memory meets the threshold defined by this parameter.
Default is 1000000 (1MB).
The WebAccelerator system writes hit log data to disk if the amount of hit log data buffered in memory meets the threshold defined by this parameter.
Default is 1000000 (1MB).
The WebAccelerator system writes change log data to disk on the interval specified by this parameter regardless of how much change data is buffered in memory.
Default is 5 minutes.
The WebAccelerator system writes hit log data to disk on the interval specified by this parameter regardless of how much hit log data is buffered in memory.
Default is 5 minutes.
The WebAccelerator system compiles all responses that it caches, and puts the responses into one of two compile queues, depending on whether the response contains Edge-Side Includes (ESI).
Compile queue
For non-ESI responses
ESI compile queue
For responses that contain ESI data
Note: If a Surrogate-Control header is located in a response, the WebAccelerator system categorizes the response as containing ESI data. For additional information about ESI support and the Surrogate-Control header, see the Policy Management Guide for the BIG-IP® WebAccelerator System.
Once it places the responses in a compile queue, the WebAccelerator system uses special threads to parse the responses. The default values for the compile queues work well, and you should not change these values unless monitoring suggests that some tuning is required. (See ESI compile queue for more information.) If you determine that you need to change the thresholds for the compile queues, you can modify the parameters located in the /config/wa/pvsystem.conf file, described in Table 4.2. After you change a parameter, save the file and then restart the process using the bigstart restart pvac command.
Warning: It is important to make only small changes to the compile queue parameters to see if it helps overall performance. Adding threads and tasks to the compile queues can actually result in slowing the WebAccelerator systems performance.
Number of threads that the WebAccelerator system uses to parse responses in the normal compile queue.
Default is 1.
Number of threads that the WebAccelerator system uses to parse responses in the ESI compile queue.
Default is 1.
Maximum number of responses allowed in the ESI compile queue. Set this number to 2 times the number of front-end connections allowed for the system.
Default is 1000.
When the WebAccelerator system receives an HTTP request that it can service from its cache, it places that request in an assembly queue. The WebAccelerator system then uses special threads to run the compiled response (including any related ESI-compiled response) and assembles the content required to respond to the request. The process of running a compiled response, in order to respond to an HTTP request, is called assembly.
The default values for the assembly queues work well, and you should not change these values unless you determine through monitoring that some tuning is required. (See Assembly queue, for more information.)
If you determine that you need to change the thresholds for the assembly queue, 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.
Warning: It is important to make only small changes to the assembly queue parameters to see if it helps overall performance. Adding threads and tasks to the assembly queues can result in slowing the WebAccelerator systems performance.
Maximum number of requests allowed in the assembly queue. You must set this number to 2 times the number of front-end connections allowed for the WebAccelerator system.
Default is 1000.
Maximum number of esi:include statements that the WebAccelerator system processes before returning a HTTP status 404 (page not found) error message to the requesting client.
Default is 50.
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.4. After you change a parameter, save the file and then restart the process using the bigstart restart pvac command.
Table 4.4 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. This value is used 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.5. 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.6. 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)