Skip to main content

Overview and Sizing Guidelines

Proper capacity planning ensures your integrations have sufficient resources to handle expected workloads while maintaining performance SLAs. This page provides sizing guidelines, resource configuration recommendations, and scaling guidance based on performance benchmarking of the WSO2 Integration Platform.

note

Capacity planning data on this page currently covers the HTTP passthrough scenario. Additional integration patterns will be added as benchmarks become available.

Key metrics for sizing

Before choosing a resource configuration, identify the following characteristics of your workload:

MetricDescription
Requests per second (RPS)Expected peak throughput your integration must sustain
Payload sizeAverage request/response payload size
Concurrent connectionsNumber of simultaneous client connections maintained toward the integration endpoint
Response latency (p99)Maximum acceptable 99th percentile response time under load

Resource configuration tiers

The following tiers reflect configurations tested in WSO2 Integration Platform capacity planning. Start with the S tier as your baseline for most workloads.

TierCPUMemoryRecommended For
XS0.2 vCPU512 MB≤100 RPS with small payloads (≤100 KB)
S0.5 vCPU1 GB100–500 RPS — recommended baseline
M1.0 vCPU1 GB500+ RPS, or medium-to-large payloads (50–100 KB)
L2.0 vCPU1 GBHigh-throughput scenarios (marginal benefit over M)

Payload size impact

Payload size is one of the strongest determinants of achievable throughput. Larger payloads increase round-trip latency, which reduces the number of requests that can be in flight at any time.

Payload SizeMaximum Achievable RPSMinimum Concurrent Connections Required
1 KB5,000500
10 KB2,000500
50 KB2,000500
100 KB500≥100
250 KB200≥50
1 MB100≥50
tip

For payloads larger than 100 KB, consider compressing data before transmission to stay within achievable throughput limits.

Resource configuration reference

Use the table below to find the recommended CPU, memory, and replica count for your target throughput and payload size. All configurations assume adequate concurrent connections (see Concurrent connections guide below).

Target ThroughputPayload SizeRecommended CPURecommended MemoryExpected Replicas
Up to 50 RPSUp to 250 KB0.2 vCPU512 MB1
Up to 50 RPS1 MB0.5 vCPU1 GB1
Up to 100 RPSUp to 100 KB0.2 vCPU512 MB1
Up to 100 RPS250 KB0.5 vCPU1 GB1
Up to 100 RPS1 MB1.0 vCPU1 GB1
101–200 RPSUp to 250 KB0.5 vCPU1 GB1
101–200 RPS1 MBNot achievable
201–500 RPSUp to 10 KB0.5 vCPU1 GB1
201–500 RPS50 KB1.0 vCPU1 GB1
201–500 RPS100 KB1.0 vCPU1 GB1
201–500 RPS250 KB+Not achievable
501–1000 RPSUp to 10 KB0.5 vCPU1 GB1
501–1000 RPS50 KB1.0 vCPU1 GB1
501–1000 RPS100 KB+Not achievable
1001–2000 RPS1 KB0.5 vCPU1 GB1
1001–2000 RPS10 KB0.5 vCPU1 GB1
1001–2000 RPS50 KB1.0 vCPU1 GB1
1001–2000 RPS100 KB+Not achievable
2001–5000 RPS1 KB0.5 vCPU1 GB1
2001–5000 RPS10 KB+Not achievable

"Not achievable" means this throughput cannot be reached for the given payload size regardless of resource allocation, due to network latency constraints.

Concurrent connections guide

The number of concurrent connections your client applications maintain toward the integration endpoint directly limits the throughput you can achieve. Insufficient connections create a bottleneck regardless of how many replicas are running.

Target ThroughputMinimum Concurrent Connections
Up to 100 RPS10 (payloads ≤100 KB)
200 RPS50
500 RPS50 (small payloads); 100 (medium payloads)
1,000 RPS100 (1 KB payload); 200 (10 KB payload)
2,000 RPS200 (1 KB); 500 (10–50 KB)
5,000 RPS500 (1 KB only)

Ensure your client connection pools are sized to maintain at least the minimum concurrent connections for your target throughput.

Deployment recommendations

  1. Start with S tier (0.5 vCPU / 1 GB) as your baseline — it provides the best cost-to-performance ratio for most workloads.
  2. Scale to M tier (1.0 vCPU / 1 GB) for payloads of 50–100 KB at moderate-to-high throughput (200–500 RPS).
  3. Right-size your client connection pools — throughput is often limited by client-side concurrency, not server resources.
  4. Compress payloads larger than 100 KB — this significantly expands the achievable throughput range.
  5. 512 MB memory is sufficient for HTTP passthrough across all tested scenarios; increase memory only if monitoring indicates otherwise.

Scaling strategies

StrategyWhen to Use
Vertical scalingQuick adjustment when a single instance is under-resourced
Horizontal scalingStateless services requiring high availability
Auto-scaling (HPA/KEDA)Variable or event-driven traffic patterns

What's next