Full Proxy Impact on Latency, Throughput, and CPU

—
Full Proxy architecture is widely used in Application Delivery Controllers, reverse proxies, WAF platforms, API gateways, and cloud application-security services.
Its main advantage is that the proxy can independently manage the client-facing and server-facing sides of a communication.
For a classic TCP Full Proxy:
Client → TCP Connection 1 → Full Proxy → TCP Connection 2 → Backend Server
This enables advanced capabilities such as:

• Independent TCP optimization

• TLS termination

• TLS re-encryption

• Layer 7 inspection

• WAF

• API security

• Application-aware routing

• Connection pooling

• Backend health monitoring

• Load balancing

However, every additional processing function consumes some combination of:

• CPU

• Memory

• Cryptographic capacity

• Packet-processing capacity

• Connection-table capacity

• Buffer space

• Network bandwidth

The three performance areas most commonly examined are:

• Latency

• Throughput

• CPU utilization

Understanding these metrics is essential when:

• Designing production architecture

• Selecting ADC or proxy capacity

• Sizing virtual appliances

• Enabling TLS inspection

• Deploying WAF

• Troubleshooting slow applications

• Planning high availability

• Comparing Full Proxy with simpler Layer 4 processing

Full Proxy Traffic Processing Pipeline

1Client2Client-Side TCP3TLS Processing4Layer 7 Parsing5Security Inspection6Load-Balancing Decision7Server-Side TCP8Backend Server

—

How Full Proxy Performance Works

A Full Proxy is different from simple packet forwarding because the intermediary actively participates in the communication.

Client-Side Processing

On the client-facing side, the proxy may perform:

• TCP connection establishment

• TCP option negotiation

• MSS handling

• Receive-window management

• TLS negotiation

• Certificate presentation

• HTTP/2 or HTTP/3 related processing where supported

• Client authentication

Application Processing

After the connection is established, the proxy may perform:

• HTTP parsing

• URI inspection

• Header processing

• Cookie processing

• WAF inspection

• API validation

• Bot detection

• Rate limiting

• Authentication

• Content routing

Server-Side Processing

The proxy may then:

• Select a healthy backend

• Establish a backend connection

• Reuse an existing backend connection

• Negotiate backend TLS

• Apply server-side TCP settings

• Forward the application request

• Process the response

This creates additional work compared with simple forwarding.

Important Performance Relationship

The amount of processing can be thought of conceptually as:
Traffic Load + Connection Load + TLS Load + Application Inspection + Security Processing + Logging = Platform Resource Consumption
The exact resource cost depends on the implementation.

—

Full Proxy Impact on Latency

Latency measures the time required for traffic or an application transaction to progress through the system.
A Full Proxy can add processing delay because it performs work that a basic forwarding device may not perform.

Sources of Additional Latency

Potential contributors include:

1. Client-side TCP connection establishment
2. Client-side TLS negotiation
3. Application parsing
4. WAF or security inspection
5. Authentication
6. Backend selection
7. Server-side connection establishment
8. Server-side TLS negotiation
9. Queueing under load
10. Response inspection

However, these activities do not necessarily occur for every application request.

Connection Reuse Changes the Picture

Consider an HTTPS application.
The first connection may require:

• TCP handshake

• TLS handshake

• Backend connection establishment

Subsequent requests may reuse existing connections.
Therefore, it is incorrect to assume:
Every HTTP request requires two new TCP handshakes and two new TLS handshakes.
Persistent connections, HTTP/2 multiplexing, connection pooling, TLS session resumption, and backend connection reuse can significantly reduce connection-establishment overhead.

Example — First Request vs Reused Connection

Suppose a client accesses:
https://shop.example.com
The first transaction may involve:

1. Client TCP handshake
2. Client TLS handshake
3. Full Proxy processing
4. Backend TCP connection
5. Backend TLS handshake
6. Application request

Later requests may reuse:

• Client TCP connection

• Client TLS session

• Backend TCP connection

• Backend TLS connection

The processing path becomes shorter.

Latency Under Normal Load

When a proxy is correctly sized, additional processing latency may be small relative to:

• Internet RTT

• WAN latency

• Application processing time

• Database response time

• Backend API calls

For example, if:
Client-to-proxy RTT: 50 ms
Backend application processing: 80 ms
Database processing: 40 ms
a small proxy-processing delay may not dominate the total user response time.

Latency Under Resource Pressure

Latency becomes more noticeable when the proxy approaches resource limits.
Possible symptoms include:

• Queueing

• Delayed connection acceptance

• Slow TLS handshakes

• Increased request-processing time

• Backend connection delay

• Packet drops

• Retransmissions

A common pattern is:
Load increases → queueing increases → latency increases → timeouts/retransmissions begin

Applications Sensitive to Latency

Latency deserves particular attention for:

• Financial trading

• Low-latency APIs

• Interactive applications

• Real-time control systems

• Gaming

• Voice signaling

• Short high-frequency API transactions

—

Full Proxy Impact on Throughput

Throughput describes how much traffic a device can process over time.
Common measurements include:

• Mbps

• Gbps

• Packets per second

• Requests per second

• Transactions per second

A network interface capable of 10 Gbps does not automatically mean the Full Proxy can process every possible 10 Gbps workload with every security feature enabled.

Why Throughput Can Decrease

Full Proxy traffic may require:

• TCP processing

• TLS encryption/decryption

• HTTP parsing

• WAF inspection

• API inspection

• Content scanning

• Logging

• Buffering

• Connection-table updates

Each feature consumes resources.

Example — Same Bandwidth, Different Workload

Consider two workloads using approximately 5 Gbps.
Workload A

• Large file transfers

• Long-lived connections

• Little application inspection

Workload B

• Very small HTTPS requests

• Thousands of new connections

• High TLS handshake rate

• WAF enabled

• Detailed logging

Both may consume similar bandwidth.
But Workload B can be significantly more demanding because it requires many more:

• Connections

• TLS operations

• Requests

• Security evaluations

Important Throughput Metrics

Do not size only by Gbps.
Also examine:
Connections Per Second — CPS
How many new connections arrive each second.
Concurrent Connections
How many active connections the system must maintain.
Requests Per Second — RPS
How many application requests are processed each second.
TLS Handshakes Per Second
How many new TLS sessions must be negotiated.
Packets Per Second — PPS
A large number of small packets can be demanding even when bandwidth is relatively low.
Transactions Per Second
Useful for application and security-processing capacity.

Full Proxy Is Not Always CPU-Bound

The original assumption that Full Proxy throughput is always CPU-bound is too broad.
A Full Proxy can become limited by:

• CPU

• Cryptographic engine

• Memory

• Packet-processing capacity

• Network interface bandwidth

• WAF engine

• Connection tables

• Buffer capacity

• Logging subsystem

• Disk I/O

• External authentication dependency

Therefore:
Throughput bottleneck = whichever resource reaches its effective limit first

Common Throughput Stressors

Examples include:

• High new-connection rate

• Large numbers of small requests

• TLS-heavy workloads

• WAF body inspection

• Large uploads

• Large API payloads

• Bot traffic

• High packet rate

• Excessive logging

• Response buffering

• Authentication processing

Full Proxy Throughput Bottlenecks

1Traffic2Network Interface3TCP Processing4TLS Processing5CPU6Memory7WAF Inspection8Logging9Backend

—

Full Proxy Impact on CPU and Memory

CPU utilization is one of the most visible Full Proxy performance metrics, but the workload behind the CPU consumption must be understood.

Major CPU Consumers

Common CPU-intensive functions include:

• TLS handshakes

• Encryption and decryption

• HTTP parsing

• WAF inspection

• API validation

• Bot detection

• Compression

• Logging

• Connection management

• Application routing

• Security signatures

TLS Processing

TLS can consume significant resources, particularly during connection establishment.
Important factors include:

• TLS version

• Cipher suite

• Key exchange

• Certificate type

• Session resumption

• New connections per second

• Hardware acceleration

TLS 1.3 and modern cryptographic implementations differ substantially from older SSL/TLS deployments, so generic statements such as RSA is always more expensive than ECDHE should not be used as universal sizing rules.

TLS Session Resumption

Session resumption can reduce repeated handshake work.
Therefore, two deployments with identical HTTPS throughput may have different CPU utilization if:

• One creates many new TLS sessions

• The other heavily reuses/resumes sessions

WAF Processing

WAF workload depends on:

• Number of rules

• Request rate

• Request size

• Response inspection

• Body inspection depth

• JSON/XML processing

• API schema validation

• Bot controls

A simple static website and a large JSON API may create very different WAF workloads.

Logging

Logging is frequently overlooked.
Potential logging workload includes:

• Access logs

• WAF logs

• TLS logs

• Audit logs

• SIEM forwarding

• Debug logging

• Request-body logging

Heavy logging can consume:

• CPU

• Memory

• Disk I/O

• Network bandwidth

Memory Consumption

Full Proxy also maintains state.
Memory can be consumed by:

• Concurrent connections

• TCP buffers

• HTTP buffers

• Persistence records

• TLS session state

• WAF processing

• Connection pools

• HA synchronization

Example — Slow Client

Suppose a backend rapidly returns a 50 MB response.
The client downloads slowly.
Depending on proxy behavior and buffering configuration, the Full Proxy may need to maintain significant connection and buffer state while the response is delivered.
A large number of slow clients can therefore create memory pressure even when backend servers are fast.

—

Performance Sizing and Optimization

Correct Full Proxy sizing requires workload information before deployment.

Traffic Baseline

Collect:

• Peak bandwidth

• Average bandwidth

• Packets per second

• New connections per second

• Concurrent connections

• Session duration

• Requests per second

• Average request size

• Average response size

• Traffic burst characteristics

TLS Requirements

Collect:

• Percentage of encrypted traffic

• TLS versions

• Cipher requirements

• New TLS sessions per second

• Session resumption rate

• mTLS requirements

• Certificate type

• Hardware cryptographic acceleration

Application Inspection

Determine whether the deployment enables:

• WAF

• API schema validation

• Request-body inspection

• Response-body inspection

• Bot mitigation

• Malware scanning

• Authentication

• Header modification

• Compression

• Caching

High Availability

HA sizing is frequently overlooked.
Consider an Active/Standby pair where one appliance normally handles the production workload.
If the active appliance fails, the standby must be able to handle the entire workload.
Therefore, capacity planning must include:

• Normal load

• Peak load

• Failover load

• Growth

• Operational headroom

CPU Headroom

There is no universal CPU percentage that is correct for every Full Proxy platform.
A fixed rule such as always stay below 70 percent should not be treated as a vendor-independent standard.
Instead:

• Follow vendor recommendations

• Observe sustained utilization

• Understand peak utilization

• Measure failover conditions

• Maintain capacity for growth and bursts

• Monitor queueing and drops

Reduce Connection Overhead

Where supported and appropriate:

• Use persistent connections

• Enable backend connection reuse

• Use connection pooling

• Use TLS session resumption

• Avoid unnecessary connection churn

Reduce Unnecessary Inspection

Apply expensive security inspection where it is actually required.
For example:

• Sensitive API → full inspection

• Static image content → different policy where appropriate

• Internal trusted application → policy based on security requirements

Optimize Logging

Consider:

• Required log types

• Log verbosity

• Sampling where supported

• Remote logging capacity

• SIEM capacity

• Debug logging duration

Monitor Backend Performance

A proxy cannot make a slow backend application inherently fast.
Measure:

• Backend response time

• Database latency

• API dependency latency

• Server CPU

• Server connection limits

—

Full Proxy Performance Sizing Checklist

Use this checklist before production deployment.

Practical Sizing Example

Consider an application with:

• Peak throughput: 4 Gbps

• Peak CPS: 12,000

• Concurrent sessions: 300,000

• Peak RPS: 45,000

• HTTPS: 100 percent

• WAF: Enabled

• API inspection: Enabled

• Average request size: 8 KB

• Average response size: 60 KB

• HA: Active/Standby

Do not select a platform simply because its interface supports 10 Gbps.
Verify that the proposed platform can support the required combination of:

• 4 Gbps inspected application traffic

• 12,000 CPS

• 300,000 concurrent sessions

• 45,000 RPS

• TLS workload

• WAF processing

• API inspection

• Failover capacity

Full Proxy Performance Sizing Workflow

1Traffic Baseline2Bandwidth3PPS4CPS5Concurrent Sessions6TLS Load7Application Inspection8Memory9Logging10HA Capacity11Growth12Platform Selection13Validation Testing

—

Troubleshooting Full Proxy Performance

When users report that the proxy is slow, troubleshoot systematically.

Step 1 — Define the Symptom

Determine whether the problem is:

• High latency

• Low throughput

• Connection failures

• TLS failures

• Intermittent drops

• Application errors

• Slow backend responses

Step 2 — Determine When It Happens

Ask:

• Always?

• Only during peak load?

• Only for HTTPS?

• Only when WAF is enabled?

• Only for one application?

• Only after failover?

Step 3 — Check Client-Side Metrics

Review:

• Client-side RTT

• Retransmissions

• Connection establishment

• TLS handshake time

• Client-side packet loss

Step 4 — Check Proxy Resources

Review:

• CPU

• Memory

• CPS

• Concurrent sessions

• TLS rate

• Packet rate

• WAF statistics

• Drop counters

• Queueing

• Logging

Step 5 — Check Server-Side Metrics

Review:

• Backend RTT

• Backend retransmissions

• Backend connection failures

• Backend response time

• Health-monitor status

Step 6 — Compare Both Sides

For a classic TCP Full Proxy, analyze:
Client ↔ Full Proxy
separately from:
Full Proxy ↔ Backend

Step 7 — Disable Features Only in Controlled Testing

If permitted in a test environment, compare performance with specific features enabled and disabled.
For example:

• WAF

• Logging

• TLS inspection

• Compression

This can help identify which processing stage contributes most to the problem.

Step 8 — Validate the Fix

After tuning:

1. Repeat the same test.
2. Compare latency.
3. Compare throughput.
4. Compare CPU and memory.
5. Compare packet loss.
6. Verify application behavior.

Full Proxy Performance Troubleshooting

1User Symptom2Client-Side Check3Proxy Resource Check4Server-Side Check5Identify Bottleneck6Controlled Feature Test7Corrective Action8Retest9Verify

—

Summary

Full Proxy architecture provides powerful application control by independently managing the client-facing and server-facing communication.
That additional intelligence requires processing resources.

Latency

Full Proxy can introduce additional processing delay through:

• TCP processing

• TLS

• Application parsing

• Security inspection

• Backend selection

However, connection reuse and session resumption can significantly reduce repeated setup overhead.
There is no universal fixed latency penalty.

Throughput

Full Proxy throughput depends on more than network-interface speed.
Important limits include:

• Gbps

• PPS

• CPS

• Concurrent connections

• RPS

• TLS capacity

• WAF processing

• Memory

• Logging

CPU

CPU can be consumed by:

• TLS

• WAF

• Application parsing

• Compression

• Connection handling

• Logging

But CPU is not the only possible bottleneck.

Final Performance Comparison

—

Useful Links and References

SanchitGurukul Static Resources

Official External References