Overview of Web Application Acceleration

Lists and describes concepts associated with the Web Application Acceleration service.

Acceleration

Accelerations are what bind web application acceleration policies to load balancers. When you attach an acceleration to a web application acceleration policy, you are assigning a load balancer to that policy, and the provisions of the policy are applied to the load balancer's operations

Caching

Enables caching at the load balancer to reduce latency and avoid increased load on the backend servers.

Cache purge

The caches of one or more load balancers comprising the acceleration are purged of data.

Note

Cache purging is an irreversible action.

Compression

Compression is an option when selecting caching. Compressions compresses backend server responses before returning them to the web application user to reduce the amount of required bandwidth. This compression speeds the server responses' transit over the network. Currently only the GZIP compression algorithm is supported.

Load balancers

Load balancers determine the traffic routing. You can enhance the performance of load balancers by assign web application acceleration policies to them through accelerations.

Web application acceleration policy

Web application acceleration policies set the parameters for applying accelerations to web traffic using caching and compression.

Web Application Acceleration is a service that can speed up traffic on your load balancers by applying a combination of caching and compression.

Caching and compression occur for any 200 response to a GET or HEAD request lower than the maximum cache size. Caching and compression do not occur when the following headers are present:

• Cache-Control: no-cache

• Cache-Control: private

Caching and compression can significantly speed up traffic on your load balancers. However, using these features has the following constraints:

• Caching

  • Only HEAD and GET requests are cached.

  • Only responses that return HTTP status code 200 are cached.

  • Cached content might not stay current with content on the backed servers until the cache expires or is purged.

  • Content is cached until it expires or is purged even if the file is removed from the backend server.

  • Backend servers can get a drastic increase in traffic when any of the following events occurs:

    • Multiple cache items expire at the same time.

    • The cache is purged.

    • The Web Application Acceleration service is disabled.

  • The maximum size of the cache is 100 MB. After this maximum size is reached, the Web Application Acceleration service removes those resources that have been accessed the fewest times until the maximum size is no longer exceeded.

    You cannot cache files over 100 MB.

    Note
    
    

    You can request to increase your Web Application Acceleration service's cache size. See Requesting a Service Limit Increase for more information.

  • Responses that return the Set-Cookie header are not cached.

  • Oracle recommends you do not cache dynamic pages because they can leak information.

• Compression:

  • If you disable compression when it was previously enabled, users of your web applications might experience increased request latency as their data downloads increase.

By default, the response is cached for 10 minutes. You can configure the cache time by setting one of the cache time response headers in response returned by the backend server.

The following cache time headers are supported:

• Cache-Control: Select the max-age or s-maxage directives to set the cache time. Both directives indicate how long in seconds the response is stored in the cache. For example, Cache-Control: max-age=300 caches the response for 300 seconds. If both the max-age and s-maxage directives are present, the s-maxage takes precedence.

• Expires: Specify the date/time after which the response is considered expired. Only use the HTTP-date format (RFC2616) to specify the date/time. For example, Expires: Mon, 20 Feb 2023 12:45:26 GMT caches the response until this date.

• X-Accel-Expires: Specify the caching time of a response in seconds. The zero (0) value disables caching for a response. If the value starts with the @ prefix, it sets an absolute time in seconds since Epoch. The response time is cached up to this time. For example, X-Accel-Expires: 300 caches the response for 300 seconds. X-Accel-Expires: @1676901818 caches the response until Monday, Feb 20 2023 14:03:38 GMT.

Configure the cache time based on the expected lifetime of a cached response. If the content that is static (immutable), configure the cache for an extended period of time. If the content changes often, configure the cache for a shorter period of time. For best results, cache the expiration time to match the content update time.