Applies To:

Show Versions Show Versions

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

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 change log and hit log information in memory until a specific threshold is reached. Once the threshold is reached, the WebAccelerator system writes the information to the hard drive.
The threshold at which the WebAccelerator system writes hit and change data to disk is based on a size limit and a Time-to-Live (TTL) value. The WebAccelerator system resets log file TTL values each time it writes the change log or hit log to disk. For example, if the WebAccelerator system writes a change log at 3 minutes because a file size has reached the limit, it resets the TTL counter to 0 and does not write the hit 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, and you should not change them unless instructed to do so by an F5 Network Technical Support Engineer.
If you are instructed to modify the size or TTL threshold default values for hit or change logs, you can make changes to the following parameters in the /config/wa/pvsystem.conf file.
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). Once it places the responses in a compile queue, the WebAccelerator system uses special threads to parse the responses.
A compile queue for non-ESI responses
An 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.
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 modify the thresholds for the compile queues, you can make changes to the following parameters in the /config/wa/pvsystem.conf file. It is important to make only small changes to these 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 found in the normal compile queue.
Default is 1.
Number of threads that the WebAccelerator system uses to parse responses found in the ESI compile queue.
Default is 1.
Maximum number of responses allowed in the ESI compile queue at any given time. 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 modify the thresholds for the assembly queue, you can make changes to the following parameters in the /config/wa/pvsystem.conf file. It is important to make only small changes to these parameters to see if it helps overall performance. Adding threads and tasks to the assembly queues can actually 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 the that the WebAccelerator system processes before returning a HTTP status 404 (page not found) 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.
To modify the system limit TTL values for compiled responses, you can make changes to the following parameters in the /config/wa/pvsystem.conf file.
Table 5.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.
Socket tunnels are a mechanism by which you can identify traffic that the WebAccelerator system should pass on to an identified host and port. You can use socket tunnels to configure the WebAccelerator system to handle traffic that should not or cannot be managed by a cache, such as SSL or FTP sessions.
You create socket tunnels by adding one or more socketTunnel parameters to the /config/wa/pvsystem.conf file. The parameter format is:
port
Is the port on the WebAccelerator system that receives the traffic that you want tunneled.
host:port
Is the host name and port to which you want the traffic tunneled.
<socketTunnel listenPort=444 remoteHost=secure1.siterequest.com:443 />
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.
You can manage cookie encryption by changing certain parameters in the /config/wa/pvsystem.conf file. Table 5.5 lists these parameters and their descriptions.
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.
You can modify the default values for the hds_prune script by changing specific parameters in the /config/wa/pvsystem.conf file. Table 5.6 lists these parameters and their descriptions.
Table 5.6 hds_prune parameters
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.
Once you have installed and configured the WebAccelerator system, you can change the default settings for certain settings by modifying /config/wa/globalfragment.xml file. This file contains the options for:
2.
Edit the /config/wa/globalfragment.xml file as required.
(The parameters for these options are specified in the following sections.)
Important: We recommend that you create a backup copy of the /config/wa/globalfragment.xml file using the
cp /config/wa/globalfragment.xml /config/wa/globalfragment.xml.back command after you make changes. This enables you to easily restore the modified configuration in case of a system failure.
The WebAccelerator system classifies, by object type, every response it receives from the origin web servers. This classification can be more accurate than deriving an object type based on the request. To classify the 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 file extension in the Content-Disposition headers extension field. If Content-Disposition headers field has an extension, the WebAccelerator system attempts to match it to an object type in the /config/wa/globalfragment.xml file. 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.
The WebAccelerator system contains a set of predefined object types in the /config/wa/globalfragment.xml file. You can modify the options for these types, or add new object types. For each object type you create, you can specify these options in the /config/wa/globalfragment.xml file. Table 5.7 lists these object type options and their descriptions.
A short name that you can use to identify the object type. This name is displayed in the X-PvInfo header for each response.
A short, arbitrary name that you can use to identify groups. This name is displayed in the X-PvInfo header for the response. This allows you to organize object types into groups.
An arbitrary category name that you can use to create a super set of groups. We recommend that you set a value for category that helps you differentiate between the predefined object types and the custom types that you create.
The values for extension define this object type. When the WebAccelerator system finds a file extension in the file name or extension field in the Content-Disposition header of the response, it attempts to match that to one of the values that you specify in the extension. If there is a match, the WebAccelerator system classifies the response as this object type. Specify as a single value or as a comma-separated list. For example:
The values for MIME type that define this object type. If the WebAccelerator system does not find an extension in the file 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 specify here. If there is a match, it classifies the response as this object type. Specify the mimeType option as a single MIME type or as a comma-separated list of MIME types. For example:
Specifies in which cases the WebAccelerator system should use gzip for the response. The values you can specify are:
none
Never compress the response.
wa
Compress the response only if the client is another WebAccelerator system.
policyControlled
Use the compression setting specified in the assembly rule that is in effect for this response
Setting this option to none or wa overrides any compression settings in the assembly rule for the node to which the response matched. If you use an object type definition to control compression (set to none or wa) or run rewrite scripts, use caution and keep the following in mind:
An object type definition applies across the entire WebAccelerator system, regardless of an application or acceleration policy. The object type setting overrides settings in all assembly rules.
Use object type for compression or rewriting only if you want the setting used for any response matching that object type across the entire system, and you do not want an assembly rule to ever affect this setting.
Specifies the name of the rewrite script that the WebAccelerator system should run against the response.
This option is not required and should only be used for very unusual cases, because it overrides any rewrite settings in the assembly rule for the node to which the response matched. You need this option only when you want the WebAccelerator system to run a particular rewrite script against responses for the specified content type, regardless as to what rules are set for the acceleration policy.
For most cases, you define the matching rules so that any response with this content type matches to it. Then you create an assembly rule that specifies the rewrite script that you want to run.
To view the current classification for an object type in a response, look for the type option that is displayed in the X-PvInfo field of the HTTP response header.
To better identify content, the WebAccelerator system analyzes the contents of a response and creates an object ID based on that specific content. The WebAccelerator system then inserts the object ID into the response returns it to the client. This process, called URL normalization, enables the WebAccelerator system to recognize content independent of the URL.
Once the WebAccelerator system performs URL normalization, it can send the normalized URL in a redirect to the browser client that sent the request. The browser can use the normalized URL to search its own cache, in case it has a copy of the content that it could not recognize based on the request URL. If the browser finds the content in its cache, the WebAccelerator system does not have to send the content. This 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 and size and contain Microsoft® Word®, Microsoft® Excel®, and Microsoft® PowerPoint® objects, or Adobe® PDF files.)
 
Has the authorization and authentication security feature disabled, and the virtual base path, where the normalized objects appear to come from, is /pv_obj_cache.
You can manage URL normalization, defining whether the WebAccelerator system uses redirects and the type of content that the WebAccelerator system redirects, by modifying the contentBasedIdentity section of the /config/wa/globalfragment.xml file.
Following is an example of the contentBasedIdentity section of the /config/wa/globalfragment.xml file:
Some of the options in the /config/wa/globalfragment.xml file currently support only one value and cannot be changed.
Table 5.8 specifies the options that you can change, and their descriptions.
Set to true or false.
When this option is set to true, normalization is enabled for the WebAccelerator system.
When this option is set to false, normalization is disabled for the WebAccelerator system.
Set to true or false.
When this option is set to true, normalization is enabled to browser clients if enableNormalization is also true. Before setting this option to true, see Enabling redirects to client browsers.
When this option is set to false, normalization is disabled to browser clients.
Specifies the object types for which normalization can occur, in addition to the object types that are part of any groups specified in groups. You specify the values in a comma-separated list. For example:
Specifies the object groups for which normalization can occur, in addition to the object types specified in types. You specify the values in a comma-separated list. For example:
Specifies the minimum size, in kilobytes, that the object must be before the WebAccelerator system can normalize it.
Specifies the virtual path on your web site from which normalized objects appear to originate. You can change this value for consistency with other URLs on your web site, so that objects appear to come from specific parts of your application.
Set to true or false.
When this option is set to true, it enables authorization and authentication. The object ID is combined with user identifier that WebAccelerator system generates it is encrypted before being used on the redirect. The user and requested document must match before the document can be retrieved using the redirect.
When this option is set to false, this feature is disabled.
If you set enableNormalizationToBrowsers to true, in the contentBasedIdentity section of the /config/wa/globalfragment.xml file, you enable redirects to client browsers. It is important to be aware of the following restrictions and security considerations associated with this setting.
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.
When you enable redirects to browsers, you should enable the security feature to restrict access to secure documents. You can do this by setting requireAuth to true. This prevents other users from finding and using the normalized URL to access content they normally would not be able to access.
If you do not want the WebAccelerator system to normalize certain URLs, you can selectively disable the content-based identity feature for specific nodes. 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.
Important: You can use the disableContentBasedIdentity setting only to disable the content-based identity, if the system-wide option is set to true. To enable content-based identity from the command line for the system, set enableNormalization to true in the /config/wa/globalfragment.xml file.
You disable content-based identity and normalization for a specific node in a user-defined acceleration policy, using an assembly rule’s advanced assembly options.
1.
On the Main tab of the navigation pane, expand WebAccelerator, and then click Policies.
The Policies screen opens displaying a table of user-defined and pre-defined 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.
In the Advanced Assembly box, type:
7.
Click the Save button.
For a modified acceleration policy to be in effect for your site, you must publish it. See the Policy Management Guide for the BIG-IP® WebAccelerator System for specific instructions on publishing acceleration policies.
Note: For more information about the Policy Tree, see the Policy Management Guide for the BIG-IP® WebAccelerator System.
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)