#Hardware requirements

Webswing hardware requirements depend mainly on the hosted application, the number of concurrent sessions, and the selected deployment architecture.

In this section, one concurrent user means one concurrent application session / JVM. A single end user may open multiple instances of the same application, and each instance should be counted as a separate concurrent session.

#Deployment options

Webswing can be deployed in two main modes:

Deployment mode	Description
Webswing Standard	Standalone deployment where all Webswing components run together. Suitable for simpler deployments, typically up to approximately 100 concurrent sessions.
Webswing Cluster	Clustered deployment with separate Cluster Server, Session Pool, and Admin Console components. Suitable for larger deployments, horizontal scaling, high availability, and Kubernetes.

In Webswing Cluster, Session Pools are usually the main scaling unit, because they run the hosted application sessions.

#Application requirements

The main factor in sizing is the resource consumption of the hosted application.

For example, assume one application session requires:

Resource	Per application session
RAM	0.64 GB
CPU	0.32 vCPU

These values represent the application session only. They do not include Webswing components, operating system overhead, Kubernetes overhead, monitoring, logging, failover capacity, or safety margin.

For 100 concurrent application sessions, the application workload would be:

Resource	Calculation	Estimated total
RAM	100 × 0.64 GB	64 GB
CPU	100 × 0.32 vCPU	32 vCPU

Because this estimate covers only the application workload, production infrastructure should provide additional capacity for platform overhead and safety margin.

As an initial production sizing example for 100 concurrent sessions, we recommend starting with a cluster of 2 servers, each with approximately:

Resource	Per server
RAM	48–64 GB
CPU	24–32 CPU cores

The exact headroom depends on the operating system, deployment architecture, monitoring and logging setup, and failover requirements.

#Webswing overhead

In addition to the hosted application, Webswing itself requires resources.

As a rough estimate, Webswing requires approximately:

Load	Webswing overhead
50 concurrent sessions	300 MB RAM and 1 CPU core

In our Kubernetes memory consumption test, Webswing Cluster was deployed with maximum isolation, where each application session ran in a separate new pod. In this configuration, the measured Webswing Cluster Server overhead was approximately:

Component	Measured RAM overhead
Per concurrent session	5 MB
Per Session Pool	3 MB

These values represent Webswing Cluster Server overhead only. They do not include the hosted application JVM, Session Pool process, operating system, container runtime, Kubernetes components, ingress, logging, monitoring, or database services.

#Sizing formula

For initial sizing, use the following formula:

Total RAM =
  concurrent sessions × RAM per application session
  + Webswing overhead
  + platform overhead
  + safety margin

Total CPU =
  concurrent sessions × CPU per application session
  + Webswing overhead
  + platform overhead
  + safety margin

Recommended safety margin:

Deployment type	Suggested safety margin
Webswing Standard	2–10%
Webswing Cluster	5–15%
Kubernetes	10–20%

#Kubernetes resource requests and limits

For Kubernetes deployments, measured application requirements should be translated into resource requests and limits.

CPU requests should cover normal steady-state usage. CPU limits should allow short-term peaks, especially during application startup or CPU-intensive workflows.

Memory requests and limits should include enough headroom for startup and peak usage. If the memory limit is too low, the application JVM or container may be terminated.

#Recommended measurement approach

Because every application behaves differently, Webswing recommends a data-driven sizing approach.

1. Run a representative test with at least 10 concurrent application sessions.
2. Measure CPU and RAM during startup, idle state, typical usage, and peak usage.
3. Extrapolate the measured values to the required number of concurrent sessions.
4. Add Webswing overhead, platform overhead, and a safety margin.
5. For production deployments, include additional capacity for monitoring, logging, failover, and expected traffic peaks.

Application startup should be measured separately from steady-state usage, because some applications require significantly more CPU or memory during startup than during normal operation.