07 Networking ‐ Load Balancer - KleberVales/OCI-Architect-Associate GitHub Wiki

1. Load Balancer

1.1 What Is a Load Balancer?

1.2 Benefits of Load Balancing

1.3 Types of Load Balancers

1.4 The Nine Load Balancer Concepts (Part 1: Concepts 1–4)

part 2

1.5 Load Balancing Policy

1.6 Shape of the Load Balancer

1.7 SSL Options

1.8 Session Persistence

1.9 Certificates

1.10 Routing Policies

2. Load Balancer Policies

2.1 Overview

2.2 How Policies Apply Across Traffic Scenarios

2.3 The Three Load Balancing Policies

3. Healthchecks

3.1 Why Health Checks Matter

3.2 What Is a Health Check?

3.3 Health Check Configuration Options

4. Public Load Balancer

4.1 Overview

4.2 OCI Networking Refresher

4.3 Placement Requirements for Public Load Balancers

4.4 Primary and Standby Load Balancers

4.5 IP Address Requirements

4.6 Architecture: Regional Subnet

4.7 Architecture: AD-Specific Subnets

5. Private Load Balancer

5.1 When to Use a Private Load Balancer

5.2 Placement and IP Addressing

5.3 Subnet Requirement

5.4 Accessibility

5.5 Floating Private IP Address

5.6 IP Address Requirements

6. Network Load Balancer

6.1 What Is a Network Load Balancer?

6.2 Load Balancing Policies

7. Web Application Acceleration Overview

7.1 What Is Web Application Acceleration?

7.2 How to Work with Web Application Acceleration

7.3 Purpose

7.4 Architecture and Anticipated Outcomes

8. Web Application Acceleration Concepts

8.1 Caching and Compression Explained

8.2 Key Concepts

8.3 Considerations for Caching and Compression

8.4 Understanding the Performance Screenshot

.
.
.
.
.

1. Load Balancer

This lesson introduced the fundamentals of load balancers. A load balancer acts as a single entry point between clients and multiple backend servers, distributing incoming traffic to ensure no single server is overwhelmed. Its three key benefits are scaling, resource utilization, and high availability. Load balancers come in two types: public (reachable from the internet via a public IP) and private (visible only within the Virtual Cloud Network via a private IP). The lesson also covered the first four of nine core load balancer concepts: backend servers (which generate content), backend sets (logical groups of servers plus health check and load balancing policies), health check policies (tests at the TCP or HTTP level that determine server health and remove failed servers from rotation), and listeners (which check for incoming traffic on the load balancer's IP address and are configured with a protocol and port number). The remaining concepts will be covered in the next lesson.

1.1 What Is a Load Balancer?

A load balancer is an entity that sits between a client and a group of backend servers. The client sends its request to a single entry point — the load balancer — which then distributes the incoming traffic across multiple backends (servers). In simple terms, instead of one server handling all requests, the load balancer spreads the traffic across several servers so that no single server is overwhelmed.

1.2 Benefits of Load Balancing

There are three main benefits:

Scaling – You can increase (or decrease) the number of backend servers at any time. For example, if you had three servers, you can easily add a fourth. This flexibility allows your system to grow with demand.
Resource Utilization – The load balancer distributes traffic to different backends based on load balancing policies, ensuring that resources are used efficiently and properly.
High Availability – Because there are multiple backends behind a load balancer, if one server becomes unhealthy, the load balancer continues sending traffic to the remaining healthy servers. This keeps your application available even when a server fails.

1.3 Types of Load Balancers

There are two types:

Public Load Balancer – Has a public IP address and is reachable from the internet.
Private Load Balancer – Has a private IP address taken from the hosting subnet where it resides. It is only visible from within the Virtual Cloud Network (VCN).

1.4 The Nine Load Balancer Concepts (Part 1: Concepts 1–4)

Concept 1: Backend Servers

Backend servers are the servers placed behind the load balancer that actually generate the content. The load balancer receives incoming traffic (which can be TCP or HTTP) and forwards or distributes it to these backend servers.

Concept 2: Backend Set

A backend set is a logical entity — essentially a list of backend servers (e.g., Backend Server 1, Backend Server 2). It also includes:

The health check policy
The load balancing policy

So a backend set = list of backend servers + health check policy + load balancing policy.

Concept 3: Health Check Policy

A health check policy is a test that confirms whether a backend server is available and healthy. If a backend server fails the test, the load balancer takes it out of rotation. There are two ways to perform a health check:

TCP level – a connection attempt
HTTP level – a request sent to a specific URI, with the response validated

The primary purpose is to determine whether backend servers are available and healthy.

Concept 4: Listener

A listener checks for incoming traffic on the load balancer's IP address. To configure a listener, you provide:

Protocol – HTTP, HTTP/2, HTTPS, or TCP
Port number

If you are handling multiple traffic types, you need to configure at least one listener per traffic type.

Load Balancer - part 2

This lesson completed the discussion of load balancer concepts by covering concepts five through nine, plus routing policies. The load balancing policy determines how traffic is distributed and includes three types: round robin (sequential, the default), least connection (fewest active connections), and IP hash (source IP as hashing key, routing non-sticky traffic to the same backend). The shape of an OCI load balancer is flexible, requiring a minimum bandwidth (for instant readiness) and a maximum bandwidth (for cost control), with a range of 10 Mbps to 8,000 Mbps. SSL can be configured in three ways: SSL termination (decrypted between LB and backend), point-to-point SSL (encrypted on both segments, with SSL re-initiated at the LB), and SSL tunneling (SSL passed through to the backend). Session persistence ensures all requests from a client go to a single backend server — useful for shopping carts and login sessions — and can be enabled via application cookie or load balancer cookie stickiness. Certificates are required when using HTTPS listeners so the load balancer can terminate connections and decrypt requests. Finally, routing policies enable path-based routing (routing by URL path such as /app, /videos, /images) and host-based routing (routing by hostname such as abc.example.com vs. xyz.example.com), each directing traffic to different backend pools.

1.5 Load Balancing Policy

The load balancing policy tells the load balancer how to distribute incoming traffic among the backend servers. There are three policies:

Round Robin – Incoming traffic is sent sequentially to each server. This is the default policy.
Least Connection – Traffic is sent to the backend server with the fewest active connections. For example, if Backend 1 has the fewest active connections, the load balancer sends traffic there.
IP Hash – The incoming source IP address is used as a hashing key. Using this policy, the load balancer routes non-sticky traffic from a particular IP address to the same backend server.

Important note: The load balancing policy applies differently depending on the traffic type:

TCP load balancers
Sticky sessions
Sticky HTTP
Non-sticky HTTP

1.6 Shape of the Load Balancer

In OCI, load balancers use a flexible shape. This means you must specify two values:

Minimum value – Specifies instant readiness for the load.
Maximum value – Gives you control over cost.

The "value" here refers to the load balancer's bandwidth. In OCI, you can specify a range from 10 Mbps to 8,000 Mbps. For example, you could set a minimum of 10 Mbps and a maximum of 3,000 Mbps.

1.7 SSL Options

SSL provides an encrypted link between parties. OCI supports three SSL configurations:

SSL Termination – The client-to-load-balancer connection is encrypted, but the load balancer decrypts the traffic and sends it unencrypted to the backend instances.
Point-to-Point SSL – SSL is terminated at the load balancer, but the load balancer then re-initiates SSL to the backend. Both segments (client-to-LB and LB-to-backend) are encrypted.
SSL Tunneling – The load balancer tunnels incoming SSL traffic directly to the backend/application server without terminating it.

1.8 Session Persistence

Session persistence means that all requests originating from a client are sent to a single backend server. This is useful for scenarios like shopping carts and login sessions, where consistent server handling matters.

There are two ways to enable session persistence:

Application cookie stickiness
Load balancer cookie stickiness

1.9 Certificates

When creating a listener that uses HTTPS, you must associate an SSL server certificate with the load balancer. Using this certificate, the load balancer terminates the connection and decrypts the request.

1.10 Routing Policies

Two additional routing capabilities can be configured using routing policies:

Path-Based Routing

The load balancer routes traffic based on the URL path. For example, with incoming traffic to www.abc.com:

abc.com/app → Backend Pool A
abc.com/videos → Backend Pool B
abc.com/images → Backend Pool C

Host-Based Routing

The load balancer routes traffic based on the hostname. For example:

abc.example.com → Backend Pool A
xyz.example.com → Backend Pool B

2. Load Balancer Policies

This lesson covered OCI's three load balancing policies — Round Robin, Least Connections, and IP Hash — and explained how each distributes traffic to backend servers, with the option to assign weights to influence distribution. The key insight is that these policies behave differently depending on the traffic scenario: for TCP load balancers, the policy and weight criteria determine only the initial request, after which all subsequent packets on that connection go to the same endpoint; for sticky HTTP requests, the backend is chosen based on cookie session information, overriding the policy; and for non-sticky HTTP requests, the policy and weight criteria are applied to every single request, meaning traffic from the same client can be spread across different servers. Round Robin, the default, distributes traffic sequentially and works best when servers have similar capacity and request loads don't vary much. Least Connections directs traffic to the server with the fewest active connections and can be weighted. IP Hash uses the source IP as a hashing key, consistently routing requests from the same client to the same backend server for non-sticky traffic. Together, these policies give you flexibility in matching traffic distribution to your application's needs.

2.1 Overview

In OCI, there are three types of load balancing policies:

Round Robin (the default)
Least Connections
IP Hash

In addition to selecting a policy, you also have the option to assign a weight to each backend server, which influences how traffic is distributed.

Importantly, these policies apply differently depending on the traffic scenario:

TCP load balancer
Sticky HTTP requests
Non-sticky HTTP requests

2.2 How Policies Apply Across Traffic Scenarios

TCP Load Balancer

The policy and weight criteria are used to direct the initial incoming request to a backend server. Once the first request is sent (for example, to Backend Server 1), all subsequent packets on that connection are sent to the same endpoint.

Sticky HTTP Requests

The request is forwarded to the backend server specified by the cookie's session information. The load balancing policy is effectively bypassed because the session determines the destination.

Non-Sticky HTTP Requests

The policy and weight criteria are applied to every incoming request. This means:

Request 1 from a client could go to Backend Server 1
Request 2 from the same client could go to Backend Server 2

2.3 The Three Load Balancing Policies

1. Round Robin (Default)

Incoming traffic is distributed sequentially to each server in the backend set list.
Example order: Server 1 → Server 2 → Server 3 → Server 4 → Server 1 → ...

When to use it:

When backend servers have similar capacity (similar virtual hardware configuration).
When the processing load required by each request does not vary significantly.

When NOT to use it:

If servers have different hardware capacities — sequential distribution would not make sense.
If requests vary significantly in processing time (e.g., one request takes 50 seconds while another takes 10 seconds).

2. Least Connections

The load balancer sends traffic to the backend server with the fewest active connections.
This balances the distribution of active connections across backends.
You can also assign weights to make it a weighted distribution.

3. IP Hash

The incoming IP address is used as a hashing key.
Based on the hash, the request is routed to a specific backend server.
This effectively sends non-sticky traffic to the same backend server — requests from the same client IP will consistently go to the same backend (as long as the IP remains the same).

3. Healthchecks

This lesson explained the purpose and configuration of load balancer health checks. Just as an unwell employee is given leave rather than assigned work, an unhealthy backend server is temporarily removed from rotation by the load balancer so it stops receiving traffic — this is what health checks accomplish. A health check continuously monitors backend servers to confirm they are healthy and available, and it can be configured in two ways: at the TCP level (a connection attempt) or at the HTTP level (a request). The chosen health check protocol should match the service or application running on the backend. Once created, a health check is configured and activated at the backend, backend set, and overall load balancer levels. Key configuration options include the protocol (HTTP or TCP), the interval (how frequently the check runs, defaulting to 10 seconds), the timeout (maximum time to wait for a reply — a reply within this window means success), and the number of retries (attempts before a server is marked unhealthy, defaulting to 3, which also applies when recovering a server back to healthy state). Together, these settings determine how quickly and reliably the load balancer detects and responds to failing backend servers, ensuring high availability for clients.

3.1 Why Health Checks Matter

Imagine a load balancer sitting in front of multiple backend servers (Backend 1, Backend 2, Backend 3). If Backend Server 1 fails, the load balancer must stop sending traffic to it — otherwise, clients would experience errors or timeouts.

This is where health checks come in.

A simple analogy: just as we undergo health checks ourselves, and when we are unwell we take leave from work so our manager doesn't assign us tasks, an unhealthy backend server is temporarily taken out of rotation by the load balancer so it stops receiving traffic.

3.2 What Is a Health Check?

A health check is a process that confirms whether backend servers are available and healthy. It continuously monitors the backend servers.

Two Ways to Configure a Health Check

TCP Level – A connection attempt to the backend server.
HTTP Level – A request sent to the backend server.

Tip: Ensure the health check protocol you select matches the service or application running on the backend.

Scope of a Health Check

When you create a health check, it is configured and activated for:

The backend
The backend set
The overall load balancer

3.3 Health Check Configuration Options

When creating a health check (via the OCI console screenshot shown in the lesson), you configure the following:

Protocol

Specify HTTP or TCP.

Interval (in milliseconds)

Specifies how frequently the health check runs.

Default: 10,000 milliseconds (10 seconds)

Timeout (in milliseconds)

Specifies the maximum time to wait for a reply to a health check.

The load balancer sends a request to the backend server and waits for a response.
If the reply returns within the timeout period, the health check is successful.

Number of Retries

Specifies the number of retries to attempt before a backend server is considered unhealthy.

This number also applies when recovering a server to the healthy state.
Default: 3

Example: Suppose the timeout is set to 3,000 milliseconds (3 seconds):

First attempt → no response within 3 seconds (retry 1)
Second attempt → no response (retry 2)
Third attempt → no response (retry 3)
After three failed attempts, the backend server is marked unhealthy.

4. Public Load Balancer

This lesson explained how public load balancers work in OCI, starting with the networking foundation of availability domains, VCNs, and the two subnet types (AD-specific and regional). A public load balancer must be deployed in a public subnet, has a public IP address, is reachable from the internet, and has a regional scope. It requires either a regional subnet or two AD-specific subnets. To ensure high availability, OCI provisions a primary and standby load balancer in different availability domains — though technically both are equivalent, and you cannot choose which is which. Each load balancer requires one private IP from its host subnet, and the service attaches a floating public IP to the primary, which switches to the standby during failover. In a regional subnet architecture, OCI automatically distributes the primary and standby across availability domains; in an AD-specific subnet architecture, the service places the active load balancer in one AD and the standby in another. In both cases, traffic normally flows through the primary load balancer, and during an availability domain outage, the standby takes over — ensuring the load balancer service remains up and running even if an entire availability domain fails.

4.1 Overview

A public load balancer in OCI is deployed in a public subnet and has a public IP address, making it directly reachable from the internet. Its scope is regional.

Before diving into the details, it's important to understand the underlying OCI networking concepts that determine where a public load balancer can be placed.

4.2 OCI Networking Refresher

Availability Domains (ADs)

In this example, we assume a multi-AD region with three availability domains:

Virtual Cloud Network (VCN)

A VCN spans across multiple availability domains.

Subnet Types

When creating a subnet in OCI, you have two options:

AD-Specific Subnet – Tied to a single availability domain (e.g., Subnet 1 in AD1, Subnet 2 in AD2, Subnet 3 in AD3).
Regional Subnet – Spans across multiple availability domains (e.g., Subnet 4).

4.3 Placement Requirements for Public Load Balancers

Key rules for public load balancers:

A public load balancer must be created in a public subnet — it cannot be created in a private subnet.
Because it resides in a public subnet, it has a public IP address and can directly receive traffic from the internet.
The scope is regional.

Subnet Requirements

A public load balancer requires either:

A regional subnet (e.g., Subnet 4), OR
Two AD-specific subnets (e.g., Subnet 1 and Subnet 2) if a regional subnet is not available.

4.4 Primary and Standby Load Balancers

To ensure high availability, the load balancer service provisions two load balancers — a primary and a standby — each in a different availability domain.

Why This Matters

If there is an outage in one availability domain, the load balancer service remains accessible because the other availability domain hosts the standby.

How Placement Works

With a regional subnet: The service places the primary and standby load balancers in different availability domains automatically.
With two AD-specific subnets: One subnet hosts the primary, and the other hosts the standby.

Important Notes

Technically, there is no difference between the primary and standby load balancers — from a service standpoint, they are equivalent.
You cannot specify which load balancer is primary and which is standby. The terms "primary" and "standby" are used only for explanation purposes.

4.5 IP Address Requirements

Whenever you provision a load balancer, it requires:

One private IP address from its host subnet (for each load balancer — primary and standby).
One public IP address.

So because there are two load balancers (primary and standby), each requires one private IP from the host subnet, in addition to the public IP.

Floating Public IP and Failover

The load balancer service attaches a floating public IP to the primary load balancer.
In case of failover, the IP switches to the standby load balancer.

4.6 Architecture: Regional Subnet

In a regional subnet deployment:

The VCN spans all availability domains.
The public load balancer is deployed in the public regional subnet.
OCI places the primary load balancer in one AD and the standby load balancer in another AD.
A public IP address is associated with the load balancer.

Normal operation (no outage):

All traffic is distributed to backend servers from the primary (active) load balancer.

Outage scenario (e.g., AD1 goes down):

Traffic is distributed to backend servers from the standby (failover) load balancer.

4.7 Architecture: AD-Specific Subnets

In an AD-specific subnet deployment:

The service provisions the active/primary load balancer in one AD.
The secondary/standby load balancer is provisioned in another AD.

This forms a load balancer pair, with the same behavior:

No outage: All traffic flows through the primary load balancer to backend servers.
Failover: Traffic flows through the standby load balancer.

5. Private Load Balancer

This lesson introduced private load balancers in OCI, which are used when you want to isolate your load balancer from the internet to strengthen your security posture. Because a private load balancer is created in a private subnet, it is assigned a private IP address that acts as the entry point for incoming traffic. Unlike a public load balancer, which requires either a regional subnet or two AD-specific subnets, a private load balancer requires only one subnet to host both the primary and standby load balancers. Being isolated from the internet, it is accessible only from within the VCN that contains the host subnet. In terms of IP addressing, a private load balancer consumes three private IP addresses from its host subnet: one for the primary, one for the standby, and one for the floating private IP address — the private equivalent of the floating public IP used by public load balancers. This floating IP enables failover between the primary and standby load balancers while keeping all traffic internal to the VCN.

5.1 When to Use a Private Load Balancer

A private load balancer is used when you want to isolate your load balancer from the internet to improve your security posture. By keeping the load balancer off the public internet, you reduce exposure to external threats.

5.2 Placement and IP Addressing

Because a private load balancer is created in a private subnet, it is assigned a private IP address. This private IP address serves as the entry point for incoming traffic.

5.3 Subnet Requirement

Unlike a public load balancer — which requires either a regional subnet or two AD-specific subnets — a private load balancer requires only one subnet to host both the primary and standby load balancers.

5.4 Accessibility

Since a private load balancer is isolated from the internet, it is accessible only from within the Virtual Cloud Network (VCN) that contains the host subnet.

5.5 Floating Private IP Address

Recall that in the public load balancer lesson, we discussed the concept of a floating public IP address. In the case of a private load balancer, the equivalent concept is a floating private IP address.

5.6 IP Address Requirements

A private load balancer created in a single subnet consumes three private IP addresses from the host subnet:

One for the primary load balancer
One for the standby load balancer
One for the floating private IP address

The primary and standby load balancers require an extra private IP address that acts as the floating private IP address — bringing the total to three private IP addresses.

6. Network Load Balancer

This lesson introduced the OCI network load balancer, a load balancing solution that operates at the connection level (Layer 3 and Layer 4). Its key characteristics include preserving the source and destination IP addresses and port, providing high throughput with ultra-low latency, and handling volatile traffic patterns — making it ideal for latency-sensitive workloads. A major advantage is that it requires no bandwidth configuration because it is elastically scalable by design, automatically adjusting to client traffic demands. The network load balancer supports three load balancing policies: the default 5-tuple hash (based on source IP, source port, destination IP, destination port, and protocol), the 3-tuple hash (source IP, destination IP, and protocol), and the 2-tuple hash (source IP and destination IP). These policies determine how incoming connections are distributed to backend servers while maintaining the high-performance, low-latency behavior that distinguishes the network load balancer from other load balancing options.

6.1 What Is a Network Load Balancer?

A network load balancer is a load balancing solution that operates at the connection level — meaning it is a Layer 3 and Layer 4 load balancer.

Key Characteristics

Preserves source and destination IP addresses and port — the original connection information is retained.
Provides high throughput while maintaining ultra-low latency.
Designed to handle volatile traffic patterns.
No bandwidth configuration required — by design, it is elastically scalable, meaning it automatically scales up and down based on client traffic.
Because of its high throughput and low latency, it is an ideal solution for latency-sensitive workloads.

6.2 Load Balancing Policies

A network load balancer supports three load balancing policies:

5-Tuple Hash (Default) – Routes incoming traffic based on a 5-tuple, which consists of:
- Source IP
- Source port
- Destination IP
- Destination port
- Protocol
3-Tuple Hash – Uses a hash of:
- Source IP
- Destination IP
- Protocol
2-Tuple Hash – Uses a hash of:
- Source IP
- Destination IP

7. Web Application Acceleration

This lesson introduced web application acceleration, an OCI service that speeds up traffic on a Layer 7 load balancer using caching and compression. To use it, you first create a web application acceleration policy, choosing either caching alone or caching combined with compression. Creating the policy alone is not sufficient — you must also create an acceleration resource to bind the policy to a specific load balancer. A single policy can be bound to multiple load balancers, but each binding requires its own acceleration resource. In a typical architecture, remote users (from on-premise or the internet) access an application through a Layer 7 load balancer with web application acceleration enabled on top. The anticipated outcomes are faster traffic, improved customer experience, reduced application latency, and reduced load on backend application servers. Caching improves application performance and decreases server load, while compression decreases network load and reduces latency — and together, they deliver the acceleration benefits that make web application acceleration a valuable enhancement for Layer 7 HTTP load balancers.

7.1 What Is Web Application Acceleration?

Web application acceleration is a service that speeds up traffic on a Layer 7 load balancer. It achieves this through two mechanisms:

Caching
Compression

By applying caching and compression, web application acceleration improves the performance of traffic flowing through a Layer 7 (HTTP) load balancer.

7.2 How to Work with Web Application Acceleration

Step 1: Create a Web Application Acceleration Policy

While creating the policy, you define what it should include. You have two choices:

Caching only
Caching and compression

Step 2: Create an Acceleration Resource

Creating the policy alone is not enough. To associate (bind) the policy to a specific load balancer, you must create a separate acceleration resource. This resource is what binds the policy to a particular load balancer.

Important Note on Multiple Load Balancers

If you have three load balancers and one policy, you can bind that single policy to each load balancer — provided you create a separate acceleration resource for each load balancer.

7.3 Purpose

The primary purpose of web application acceleration is to speed up traffic on your Layer 7 (HTTP) load balancer by applying a combination of caching and compression.

7.4 Architecture and Anticipated Outcomes

The Setup

Consider an application hosting tenancy with two types of users:

Remote users from an on-premise environment
Internet users

Both types of users access the application via the Layer 7 load balancer. Web application acceleration is enabled on top of this Layer 7 load balancer.

Anticipated Outcomes

The goals of enabling web application acceleration are to:

Speed up traffic on the load balancer
Improve customer experience
Reduce application latency
Reduce load on backend application servers

How Each Mechanism Helps

Scenario	Mechanism	Outcome
1	Caching	Improves application performance and decreases server load
2	Compression	Decreases network load, which in turn reduces latency

By combining caching and compression, you can speed up traffic on your Layer 7 HTTP load balancer.

Policy Reminder

As discussed, when you create a web application acceleration policy, you can choose either:

Caching, or
Caching and compression

8. Web Application Acceleration Concepts

This lesson explained the core concepts behind web application acceleration, which works only with Layer 7 load balancers. Caching stores backend response data at the load balancer, reducing backend load and latency by serving future requests directly from the cache. Compression (only gzip is supported) shrinks backend responses before sending them to the client, reducing bandwidth usage and speeding up network transmission. To use the service, you create a policy (caching, or caching plus compression) and bind it to a load balancer via an acceleration. Cache purge removes cached data — an irreversible action — causing requests to be served from backends again. Key considerations include: only HTTP 200 responses to GET and HEAD requests are cached; the maximum cache size is 100 MB, with least-accessed resources purged first; the default cache duration is 10 minutes, with longer or shorter times recommended based on whether content is static or changes often; responses with the Set-Cookie header are not cached; and dynamic pages should not be cached due to potential leakage of secrets like OAuth state parameters. The lesson concluded with a performance comparison showing that compression reduces client-received and load-balancer-sent bytes, while caching dramatically reduces backend bytes sent — together delivering faster, more efficient application delivery.

8.1 Caching and Compression Explained

Caching

Imagine a Layer 7 load balancer sitting in front of three backend servers. An application user sends a request to the load balancer, which distributes it to the backend pool, and the response is served back to the user.

When web application acceleration is enabled, the load balancer caches some data from the backend responses.

Why cache? Two main reasons:

Reduced load on backend servers – Future requests can be served directly from the load balancer.
Reduced latency – The request is served from the load balancer rather than traveling to the backend servers.

Compression

Compression means that backend server responses are compressed before being returned to the web application user.

Two advantages:

Reduced bandwidth required.
Increased speed of the server's response over the network.

Note: Currently, only the gzip compression algorithm is supported by web application acceleration.

8.1 Key Concepts

Acceleration

The service is called web application acceleration. To use it:

You create a policy (defining whether to use caching, or caching and compression).
You bind that policy to a load balancer through an acceleration.

When you attach an acceleration to a web application acceleration policy, you are essentially assigning a load balancer to that policy. Whatever is defined in the policy (compression and/or caching) is applied to the load balancer's operation.

Cache Purge

Cache purge means removing the cached data. After purging:

Requests are served by the backend servers rather than the load balancer (since the cache is gone).

Important: Cache purge is usually an irreversible action — once you perform it, you cannot restore the cache.

8.3 Considerations for Caching and Compression

HTTP Status Code Requirements

Only responses that return HTTP status code 200 are cached.
Caching and compression occur only for HTTP 200 responses to GET and HEAD requests.

Maximum Cache Size

The cache can be at most 100 MB.
When the cache reaches this size, the service removes resources that have been accessed the fewest times.
In other words, it retains frequently accessed resources and purges the least-used ones.

Cache Duration

By default, responses are cached for 10 minutes.
You can configure the cache time, and there are guidelines:
- Static content → configure cache for an extended period.
- Content that changes often → configure cache for a shorter period.

Additional Considerations

Backend content can change while cached content becomes outdated — this is why manual cache purging is sometimes needed.
Until cached content expires or is manually purged, it remains available even if the file is removed from the backend server.
If backend responses return the Set-Cookie header, they are not cached.
Oracle recommends not caching dynamic pages — even if publicly accessible or behind authentication, they may contain secrets like OAuth state parameters, which could leak information if stolen.

8.4 Understanding the Performance Screenshot

The screenshot compares three parameters before and after enabling web application acceleration:

Parameter	Effect After Enabling WAA	Reason
Client — bytes received	Gradual decrease	Compression enabled — client receives compressed data
Load balancer — bytes sent	Reduction	Compression enabled
Backend — bytes sent	Drastic reduction	Caching enabled — most requests served from cache, so backend sends less data

The dip in the first two parameters is due to compression, while the drastic reduction in backend bytes sent is due to caching.