Overview of the WebAccelerator System
Introducing the WebAccelerator system
The WebAccelerator system is designed to increase the performance of web applications (such as Microsoft® Sharepoint, Microsoft® Outlook Web Access, Plumtree®, SAP® Portal, Siebel™, Oracle® Portal, and others). The WebAccelerator system does this by modifying the web browser's behavior and interaction with the web application, as well as by compressing and caching dynamic and static content to reduce traffic to the web application servers.
The following figure illustrates the basic configuration for the WebAccelerator system.
Figure 2.1 Basic WebAccelerator system configuration
The WebAccelerator system benefits include:
- Browser behavior control
Without requiring changes to the browser, the WebAccelerator system ensures that users do not download duplicate content.
- Content acceleration
The WebAccelerator system provides content acceleration by:
- Opening additional simultaneous browser connections
- Rapidly displaying PDF documents
- Accelerating dynamic content
- Using software compression for web applications
- Using dynamic and static caching for web applications
- Reports and logs
The WebAccelerator system provides:
WebAccelerator system processes
The WebAccelerator system consists of the following processes:
- Communications server
Manages the communications between all WebAccelerator system processes.
Manages HTTP traffic.
- HDS prune
Manages the on-disk cache and removes data once specified thresholds are met.
Servicing HTTP traffic
Most sites are built on a collection of web servers, application servers, and database servers that we refer to collectively as origin servers. Origin servers can serve all possible permutations of the content offered by your site, while the WebAccelerator system only stores and serves page content combinations that were previously requested by clients visiting your site. By serving the bulk of common requests, the WebAccelerator system significantly reduces the load on the origin servers, which improves performance for your site.
Once installed, the WebAccelerator system receives all requests destined for the origin server. The first time a client makes a request for a specific page, the WebAccelerator system relays the request to the origin server, and attempts to cache the response that it receives, before forwarding the response to the client. The next time a client requests the same page, the WebAccelerator system serves the response from its cache, instead of sending the request to the origin servers.
This means that for each HTTP request it receives, the WebAccelerator system performs one of the following actions:
- Services the request from its cache
Upon receiving a request from a browser or web client, the WebAccelerator system initially checks to see if it can service the request from compiled responses in its cache.
- Sends the request to the origin servers
If the WebAccelerator system is unable to service the request from its cache, it sends a request to the origin server. Once it receives a response from the origin server, the WebAccelerator system caches that response according to the acceleration policy rules, and then forwards the request to the client.
- Redirects the request to the origin servers
The WebAccelerator system redirects requests for some pre-defined types of content, such as requests for streaming video.
- Creates a tunnel to send the request to the origin servers
You can use tunneling for encrypted traffic (HTTPS) content that you do not want processed by the WebAccelerator system. Note that the WebAccelerator system can cache and respond to SSL traffic without using tunnels.
The first time that a WebAccelerator system receives new content for a request that it sends to the origin server, it process the information as follows, before returning the requested page (response) to the client:
- Compiles an internal representation of the page
The WebAccelerator system uses these compiled responses to recreate a page in response to an HTTP request. Compiled responses consist of:
- An internal representation of the page, as it was received from the origin site
- Instructions that describe how to recreate the page from the internal representation, including information needed to update the page with any random or rotating content
(For additional information about assembly rules, see Chapter 8, Configuring Assembly Rules, in the Policy Management Guide for the BIG-IP WebAccelerator Module.)
- Assigns a Unique Content Identifier (UCI) to the compiled response, based on elements present in the request
The origin servers generate specific responses based on certain elements in the request, such as the URI and query parameters. The WebAccelerator system uses these specific elements as part of the identifier to easily match future requests to the correct content in its cache. The WebAccelerator system uses the UCI for both the request and the compiled response that it created to service the request.
The flow for the request and response follows a general pattern, as illustrated in the following diagram.
Figure 2.2 Request/Response Flow
- Web clients, using web browsers, request pages from your site. From their perspective, they are connecting directly to your site; they have no knowledge of the WebAccelerator system.
- The WebAccelerator system examines the request to determine if it meets all the HTTP requirements needed to attempt to service the request from a compiled response in its cache.
If it does not meet the HTTP requirements, the WebAccelerator system issues a redirect to the client, the client re-sends the request directly to the origin servers, and the origin servers respond to the request. (For information about the what the WebAccelerator system requires to service a request, see Appendix A, Requirements for Cache Behavior in the Policy Management Guide for the BIG-IP WebAccelerator Module.)
- If the WebAccelerator system can service the request from a compiled response, it reviews the request elements and creates a UCI for the request. The WebAccelerator system then reviews its cache to see if it has a compiled response stored under that same UCI. At this point, one of the following occurs:
- If the page is being requested for the first time (there is no matching compiled response in cache), the WebAccelerator system uses the host map to relay the request to the appropriate origin server.
- If a page with the same UCI is already stored as a compiled response in the WebAccelerator system's cache, the WebAccelerator system checks to see if the content has expired. If the content has expired, the WebAccelerator system checks to see if the information in its cache still matches the origin server. If it does, the WebAccelerator system skips to step 7.
- The origin server either responds or queries the application servers or databases for input to the page.
- The application servers or databases provide the input back to the origin server.
- The origin server replies to the WebAccelerator system with the requested material and the WebAccelerator system compiles the response. If the response meets the appropriate requirements, the WebAccelerator system stores the compiled response in its cache under the appropriate UCI. (For more information about HTTP response requirements, see Appendix B, Processing HTTP Response Headers in the Policy Management Guide for the BIG-IP WebAccelerator Module.)
- The WebAccelerator system uses the compiled response to create the page and respond to the request.
- The WebAccelerator system directs the response to the originator of the request.
The WebAccelerator system uses queues when caching data and responding to HTTP requests. It is important for you to monitor these queues, because their size can limit the WebAccelerator system's performance.
When the WebAccelerator system forwards a request to the origin servers and receives a response to accelerate, it compiles that response into an internal format. The WebAccelerator system then uses the compiled response object to assemble responses.
To perform compilation, the WebAccelerator system uses one of the following two queues.
- Compile queue
For compiling responses that do not include ESI data.
- ESI compile queue
For compiling responses that contain ESI data.
If the response contains a Surrogate-Control header, the WebAccelerator system categorizes it as containing ESI data.
It is important that you monitor the compile queue and the ESI compile queue. If these queues grow too large, it can slow response time. For information about queue size parameters and monitoring the compile queues, see Monitoring the compile queue , located in Chapter 6, and Monitoring the ESI compile queue , located in Chapter 6.
Before a WebAccelerator system can respond to a client request, it must assemble the compiled response. This assembly involves performing any required parameter substitution and running any ESI statements embedded in the page. After completing the assembly, the WebAccelerator system responds to the client request with the assembled web page.
All HTTP requests that the WebAccelerator system can service are placed in an assembly queue. It is important to monitor the size of the assembly queue to make sure that responses to requests are swift. If the assembly queue is too large, then your site appears slow to its users. For more information, see Monitoring the assembly queue , located in Chapter 6.
Generating log files
The WebAccelerator system generates two types of log files:
- Change logs
These are used to pass data between WebAccelerator system processes and to populate the content displayed in the Performance Report. The Performance Report includes information about page requests, the frequency of those requests, and how well the WebAccelerator system serviced those requests from its cache.
- Hit logs
These contain the same type of information as in the web server log files. Hit logs are not enabled by default. (For information about how to enable customize the content for the hit logs, see the Chapter 14, Specifying Log Formats, in the Policy Management Guide for the BIG-IP WebAccelerator Module.)
By default, the WebAccelerator system monitors these files on an hourly basis. For information about how to configure log file rotation, see Changing log file monitoring parameters , located in Chapter 3.