Troubleshooting Web Content Accelerator
Certain UI controls and configuration options mentioned in this section do not apply if you are using Web Content Accelerator Express.
Controlling Unexpected Behavior
When the Virtual Traffic Manager encounters problematic or non-standard user-defined content, the Web Content Accelerator process could be forced into a failure state. If this occurs, the Virtual Traffic Manager records the failure with an error message in the event log and restarts the process.
In certain circumstances, error-prone content could force repeated failures and restarts of the Web Content Accelerator process. This can hinder the overall performance of the Virtual Traffic Manager and make troubleshooting efforts more difficult. Therefore, the Virtual Traffic Manager provides a “watchdog” capability to stem the effect of frequent failures by disabling the Web Content Accelerator process restart once a set limit has been reached.
To set your watchdog configuration, click System > Global Settings > Web Content Accelerator. This section contains the following settings:
Setting | Description |
|---|---|
| This is the maximum number of times the Web Content Accelerator process will be started or restarted within the interval defined by the aptimizer!watchdog_interval setting. If the process fails this many times on one Virtual Traffic Manager, Web Content Accelerator will be disabled on all Virtual Traffic Managers in the cluster, and it must be restarted manually from the System > Diagnose page. If this limit is set to zero, Web Content Accelerator will never be disabled. |
aptimizer!watchdog_interval | The period of time (in seconds) after which a previous failure will no longer count towards the limit set by aptimizer!watchdog_limit. |
Most users should not have to use or modify these settings. If you do find that Web Content Accelerator fails frequently, contact your support provider.
For details about other Web Content Accelerator global settings, see Other Configurable Global Settings.
Interaction with Other Virtual Traffic Manager Functionality
In practice, enabling Web Content Accelerator on your virtual server should present no interoperability issues with other Virtual Traffic Manager functionality. However, due to the nature of certain built-in protection and performance capabilities, it is important to understand the interactions between Web Content Accelerator and these other features.
Problems with Dependent Requests
The following diagrams demonstrate the consequences of what are termed “dependent requests”. These are requests that follow a Web page request handled by the Virtual Traffic Manager, for dependent resources contained within that returned page.
Initially, the client requests a Web page for a service handled by the Virtual Traffic Manager. Web Content Accelerator is enabled for this Web application and will attempt to identify resources that are potentially optimizable.
The Virtual Traffic Manager might then need to make a number of additional dependent requests in order to locate and provide the various resources that have been stripped or optimized out in order to improve the page load time of your application.
After they have been fetched, suitable resources are optimized and cached locally by Web Content Accelerator. Subsequent page requests contain modified URLs to optimized content, which can be served directly from the Virtual Traffic Manager.
Dependent requests are processed through the Virtual Traffic Manager as typical requests, with the usual processing applied. However these requests do not necessarily contain the same identifying headers, cookies and other elements of authentication as the requests and responses made directly through the Web Content Accelerator, so can cause potentially unexpected results.
The following sections highlight the issues surrounding the fetching of these dependent requests.
Service Protection
The fetching of dependent requests could in some cases trigger Service Protection classes to be activated (since the requests will come in bursts from one of the Virtual Traffic Managers in your cluster). This can be prevented by adding the appropriate Virtual Traffic Manager IP addresses to the list of Allowed IPs (also known as whitelisting) maintained within the Access Restrictions section of the class configuration. For further details about Service Protection features and capabilities, see Service Protection.
TrafficScript Rules
The typical processing order for TrafficScript rules when Web Content Accelerator is enabled runs as follows:
- For a request:
Client request received -> TS request rules -> Web Content Accelerator -> Sent to back-end node
- For a response:
Response received from back end -> TS response rules -> Web Content Accelerator -> Sent to client
With respect to dependent requests, TrafficScript rules are run in the usual way.
TrafficScript rules that rely on the client IP address, browser headers, cookies, authentication data, or any other information pertaining to the client, could result in unexpected behavior due to the lack of such information in dependent requests.
Note also that use of the http.stream.* TrafficScript functions will prevent responses from being optimized.
SSL Decryption
The Virtual Traffic Manager cannot be used to optimize virtual servers that use SSL decryption and require client certificates. This is because a client certificate is not provided when Web Content Accelerator initiates fetches for additional resources.
Authentication
In Express mode, the Virtual Traffic Manager cannot be used to optimize any services employing authentication. In Enterprise mode, the Virtual Traffic Manager can optimize services using NTLM. No other client authentication methods are supported.
Content Caching
Web content that is passed through Web Content Accelerator and can be considered to be in scope with Web Content Accelerator will not be cached in the usual way within the regular Virtual Traffic Manager Web cache. Instead, it will be held and served from a dedicated Web Content Accelerator cache, designed to maintain local copies of optimized Web content/resources. To control this behavior, use the settings contained in the "Caching" tab on the Web Content Accelerator Profile edit page.
Runtime Errors
Runtime errors are generally server-related. You can get these errors due to server misconfiguration or third party interference (routers, firewalls, load balancers). In general you might not be able to access the Web site at all, of if you can access the Web site you might experience missing resources.
Symptom: An error page is displayed only when Web Content Accelerator is enabled; resources are served with a 400 or 404 http status; the server takes a long time to return Web pages even though the application pool is warm.
- Problem: A URL rewriter or other HttpModule is attempting to handle the Web Content Accelerator resource set URLs.
- Resolution: Exclude URLs containing /optimized-gif-*.gif from URL rewriting or processing by another HttpModule.
Symptom: The Web service works when accessed locally but not when accessed from external clients.
- Problem: A proxy or upstream device is blocking or altering /optimized-gif-*.gif URLs causing them to become invalid.
- Resolution: Allow requests for /optimized-* to pass through to the host server unmodified.
Symptom: Cannot see the comment “<!-- Optimized for speed – Web Accelerator -->” in the HTML.
- Problem: When you use your browser’s “View HTML Source” the comment “<!-- Optimized for speed – Web Accelerator -->” is not present, indicating the Web page is not being accelerated.
- Resolutions:
- Make sure Web Content Accelerator is enabled for the specific virtual server.
- Make sure the URL is not being excluded by a rule set.
- If Web Content Accelerator is running in Stealth Mode use the ?aptimizer=on query string in the URL request.
- If the URL is not being excluded, Web Content Accelerator is fully enabled, make sure ?aptimizer=off is not used in the URL request.
Image Errors
You might observe image errors if your Web pages do not display images in their specified position or display images with incorrect size. Image errors can also be “invisible”, as it is the case when Web Content Accelerator creates new resource sets for every new visit to the page.
You can spot the problem with resource set creation by inspecting the elements on the page. You should see the most common elements being created once and served from the cache multiple times.
Symptom: A new sprite set seems to be created every time I visit the page.
- Problem: The list of images in the page is different every time, which causes Web Content Accelerator to create a new sprite set every page visit. This can cause excessive processor utilization, high cache memory usage, and overall reduced performance on the server.
- Resolution: Add a URL rule to include the dynamic images in an uncombined form (disable the setting Combine HTML images into image sprites in the Images tab).
Symptom: Images on the page are losing their padding or out of alignment on the page.
- Problem: Padding is being used to space the image from its neighboring UI elements.
- Resolution: Add a URL rule to include the dynamic images in an uncombined form (for example, disable the setting Combine HTML images into image sprites in the Images tab).
Symptom: One of the images appears much larger when Web Content Accelerator is enabled.
- Problem: The container that holds the image uses style sheet to resize the image from its native dimensions.
- Resolutions:
- Modify the page template to include a width and height attribute on the <img> element. This lets Web Content Accelerator know what size the image should be displayed at, and also helps the browser calculate the page layout more quickly, resulting in a faster rendering time.
- Add a URL rule to include the dynamic images in an uncombined form (for example, disable the setting Combine HTML images into image sprites in the Images tab).
Symptom: Acceleration is working but there is a layout problem.
- Problem: This is normally style sheet or HTML image related.
- Resolution: Reduce the number of style sheet objects and HTML images. This problem typically requires the use of acceleration rules to work around whatever technique is causing this symptom to appear.
CSS Errors
You could have image errors if your Web pages do not display images in their specified position or display images with incorrect size. Image errors can also be “invisible”, as it is the case when Web Content Accelerator creates new resource sets for every new visit to the page.
You can spot the problem with resource set creation by inspecting the elements on the page. You should see the most common elements being created once and served from the cache multiple times.
Symptom: Internet Explorer does not apply background images defined in a style sheet.
- Problem: The cause is the security policy that Internet Explorer is enforcing. If an HTML page on one domain references a resource on a different domain and that resource type is rfc822 then the browser will load it but not process it since it does not know if it can be trusted. External resources on the same TLD as the page are implicitly trusted.
- Resolution: Change the CDN hostname to be a subdomain of the main Web site so that resources are implicitly trusted.
JavaScript Errors
It is important to ensure any JavaScript errors, as detected by most modern browsers, do not exist before enabling Web Content Accelerator. This will help determine if these problems are caused by any of the introduced optimizations. If in doubt, request the page again with Web Content Accelerator disabled. This will bypass the accelerator and you can then check if JavaScript errors exist regardless of the optimizations.
On Internet Explorer 9 you have access to Developer Tools and debug information. On Firefox and Chrome you can install the Firebug add-on and access similar information. Most browsers offer an identifying message/notification when JavaScript errors are encountered regardless of installed tools and plug-ins. This message is usually helpful in disclosing which script is causing problems and frequently also identifies the specific position or line number of the erroneous section of code.
Debugging JavaScript Errors
Because Web Content Accelerator allows you to apply rules to specific URLs, you can switch off certain optimizations for individual (or a group of) resources without compromising the default settings for your Web site.
To resolve JavaScript issues with Web Content Accelerator enabled you can perform one or more of the following:
- Disable the JavaScript optimization option on the JavaScript tab of any matching rules
- Identify which script is breaking and create a URL rule to exclude it completely from optimization
- You can verify Web Content Accelerator is causing JavaScript errors quickly by excluding all JavaScript optimization on your web site. Create a temporary URL rule to exclude all optimization for any URLs containing “.js”.
Common JavaScript Errors
Symptoms: Scripts execute with unpredictable results.
- Problem: Errors due to an external script reference having been moved in the page.
- Resolution: If order-dependent code exists between the external script and other script files or an inline script block, then this may prevent normal functioning of the site. Best practice for building JavaScript libraries is to treat them as libraries of functions, and not execute any immediate code. This allows script to be combined to the maximum extent possible. To work around poorly designed script you can instruct Web Content Accelerator to exclude them entirely via a suitable URL rule.
Symptoms: Scripts fail to load and execute.
- Problem: JavaScript frameworks that dynamically load script libraries into the page.
- Resolution: These frameworks typically look for a reference to one of the scripts that they use, or will use some sort of registration function to inject the scripts that should be loaded. Since Web Content Accelerator refers to combined scripts using a surrogate URL, this can confuse frameworks that behave like this. The solution in this case is to either exclude these scripts, or transform the loading code such that it understands Web Content Accelerator modifications.
Symptom: Some JavaScript is not executed on a Web page when using the JavaScript async option.
- Problem: Some ad blocking software will incorrectly filter out the Web Content Accelerator code injected to asynchronously load and execute JavaScript.
- Resolution: Use a URL rule to exclude required scripts from the async code, or disable the option to load and execute JavaScript in asynchronous mode.
Other Configurable Global Settings
The Virtual Traffic Manager provides further configurable global settings at System > Global Settings > Web Content Accelerator. This section contains the following settings:
Setting | Description |
|---|---|
aptimizer!max_original_content_buffer_size | The maximum content size of a single back-end response that can undergo Web Content Accelerator optimization. Responses larger than this are returned to the client un-optimized. If the back-end response is compressed, this setting pertains to the compressed size of the response body. |
aptimizer!max_dependent_fetch_size | The maximum the size of a dependent resource (a resource that Web Content Accelerator has requested from the back end, as a piece of content currently undergoing optimization depends on it) that can be sent to, and processed by, the Web Content Accelerator sub-process. Any resource larger than this value is always ignored by Web Content Accelerator and returned to the client un-optimized. Set this field to zero to disable the limit. |
You do not normally need to alter these settings. The Virtual Traffic Manager uses default values that typically provide a good level of performance on all systems.