Applies To:

Show Versions Show Versions

Manual Chapter: Overview of the WebAccelerator System
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

The BIG-IP® WebAccelerator system is an advanced web application delivery solution that provides a series of intelligent technologies designed to overcome latency issues that impact user performance when using web browsers to access web applications and wide area networks (WAN). Installed on your network between the users of your applications and the servers on which the applications run, the WebAccelerator system accelerates your applications response to HTTP requests.
Most sites are built on a collection of web servers, application servers, and database servers that we refer to collectively as origin web servers. Origin web servers can serve all possible permutations of content, while the WebAccelerator system only stores and serves page content that clients have previously requested from your site. By transparently servicing the bulk of common requests, the WebAccelerator system significantly reduces the load on the origin web servers, which improves performance for your site.
Once installed, the WebAccelerator system receives all requests destined for the origin web server. When a client makes an initial request for a specific page, the WebAccelerator system relays the request to the origin web server, and caches 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 web servers.
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 web servers
If the WebAccelerator system is unable to service the request from its cache, it sends a request to the origin web server. Once it receives a response from the origin web server, the WebAccelerator system caches that response according to the associated acceleration policy rules, and then forwards the request to the client.
Relays the request to the origin web servers
The WebAccelerator system relays requests directly to the origin web server, for some pre-defined types of content, such as requests for streaming video.
Creates a tunnel to send the request to the origin web servers
For any encrypted traffic (HTTPS) content that you do not want the WebAccelerator system to process, you can use tunneling. Note that the WebAccelerator system can cache and respond to SSL traffic without using tunnels.
To perform the processes required to manage HTTP traffic, the WebAccelerator system uses the following services:
Communications server
This service manages the communications between all WebAccelerator system processes.
HDS prune
This service manages the on-disk cache and removes compiled responses that are no longer needed. For more information about HDS prune, see Changing default values for HDS prune.
pvac
This service manages HTTP traffic in accordance with the options defined in the associated acceleration policy.
waicd
This service manages the communications between peer WebAccelerator systems in a symmetric deployment.
The first time that a WebAccelerator system receives new content from the origin web server in response to an HTTP request, it processes the information as follows, before returning the requested page (response) to the client:
Compiles an internal representation of the page
The WebAccelerator system uses compiled responses received from the origin web server, to assemble a page in response to an HTTP request.
Assigns a Unique Content Identifier (UCI) to the compiled response, based on elements present in the request
The origin web server generates specific responses based on certain elements in the request, such as the URI and query parameters. The WebAccelerator system includes these elements in a UCI that it creates, so that it can easily match future requests to the correct content in its cache. The WebAccelerator system matches content to the UCI for both the request and the compiled response that it created to service the request.
1.
Clients, using web browsers, request pages from your site. From the clients perspective, they are connecting directly to your site; they have no knowledge of the WebAccelerator system.
2.
The WebAccelerator system examines the clients request to determine if it meets all the HTTP requirements needed to service the request.
If the request does not meet the HTTP requirements, the WebAccelerator system issues an error to the client. (For information about what the WebAccelerator system requires to service a request, see the Policy Management Guide for the BIG-IP® WebAccelerator System.)
3.
The WebAccelerator system examines the request elements and creates a UCI, and then reviews its cache to see if it has a compiled response stored under that same UCI. At this point, the WebAccelerator system processes it in one of the following ways:
If the content is being requested for the first time (there is no matching compiled response in the WebAccelerator systems cache), the WebAccelerator system uses the host map to relay the request to the appropriate origin web server to get the required content.
If content with the same UCI is already stored as a compiled response in the WebAccelerator systems 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 web server. If it does, the WebAccelerator system moves directly to step 7. Otherwise, it performs the following step.
6.
The origin web 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 the Policy Management Guide for the BIG-IP® WebAccelerator System.)
7.
The WebAccelerator system uses the compiled response, and any associated assembly rule parameters, to recreate the page. The assembly rule parameters dictate how to update the page with generated content. (For information about assembly rules, see the chapter, Configuring Assembly Rules, in the Policy Management Guide for the BIG-IP® WebAccelerator System.)
When the WebAccelerator system forwards a request to the origin web servers and receives a response to accelerate, it compiles that response into an internal format. The WebAccelerator system uses the compiled response object to assemble responses. Depending on the type of information in the response, the WebAccelerator system uses one of the following queues to perform compilation.
Compile queue
The WebAccelerator system uses a compile queue for responses that do not include ESI data.
ESI compile queue
The WebAccelerator system uses an ESI compile queue for responses that contain a Surrogate-Control header.
It is important that you monitor these queues, because if they grow too large, it can slow the WebAccelerator systems response time.
For information about how to monitor the compile queues, see Compile queue, and ESI compile queue. For additional information about configuration options for the compile queues, see Changing default values for the compile queues.
Before a WebAccelerator system can respond to a client request, it must assemble the compiled response it created. The assembly process involves performing any required parameter substitution defined in the assembly rule and running any ESI statements embedded in the page. After completing the assembly process, the WebAccelerator system responds to the client request with the assembled web page.
All HTTP requests that the WebAccelerator system can service from cache are placed in an assembly queue. It is important to monitor the size of the assembly queue to make sure the WebAccelerator system can respond swiftly to responses. If the assembly queue is too large, then your site appears slow to its users.
For information about how to monitor the assembly queues see Assembly queue. For additional information about configuration options for the assembly queue, see Changing default values for the assembly queue.
Change logs
These logs are used to pass data between WebAccelerator system processes and to populate the content displayed in the Performance Reports. For information about Performance Reports, see Using performance reports.
Hit logs
These logs contain the same type of information as the HTTP web server log files. Hit logs are disabled by default. For information about how to enable customize the content for the hit logs, see the chapter, Specifying Log Formats, in 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)