Capacity Planning and Sizing Guide

Capacity planning for IMTerm is straightforward: the limiting resource is RAM, not CPU. Each TN5250E or TN3270E session uses approximately 32 MB of resident memory. CPU consumption per session is negligible - a modern server with 32 GB of RAM can comfortably handle hundreds of simultaneous users.

The Rule: RAM, Not CPU

Each active terminal session (5250 or 3270) consumes approximately 32 MB of RAM for its TN5250E or TN3270E connection state, WebSocket, screen buffer, and associated Go runtime overhead. CPU usage per session is under 1% of a single core during normal operation (screen redraws, keystrokes). The Go garbage collector adds brief GC pauses, but these are imperceptible to users.

VT220/SSH sessions consume somewhat less (around 16-24 MB each) because the data stream is simpler. Use the 32 MB figure for planning if your environment is primarily 5250 or 3270.

Sizing Formula

safe_sessions = floor((available_ram_gb - os_reserve_gb) / 0.032 * 0.80)

The 0.80 factor is a 20% safety margin for burst load, GC pressure, and audit log writes. Always plan to the safe figure, not the theoretical maximum.

Breaking it down:

• available_ram_gb - total RAM installed on the server
• os_reserve_gb - memory reserved for the OS, other processes, and IMTerm's own base footprint (see table below)
• / 0.032 - divides remaining RAM by 32 MB per session (converted to GB)
• * 0.80 - 20% safety margin

OS Memory Reserve

Sizing Table

For a 2-node cluster, the total safe capacity is 2x the per-node figure. Plan so that if one node fails, the surviving node can absorb the full concurrent load from the failed node.

Worked Example: 2000-Seat Deployment

An organization has 2,000 total users (AS/400 operators) and wants to size an IMTerm cluster. Historical data shows a 40% concurrency ratio during peak hours - at most 40% of all users are connected simultaneously.

• Peak concurrent sessions: 2,000 x 40% = 800 sessions
• HA requirement: the cluster must survive the loss of one node while still serving all 800 sessions
• Therefore each node must handle 800 sessions alone
• RAM required per node: 800 sessions x 32 MB / 0.80 (margin) = 32,000 MB = 32 GB RAM
• Recommended configuration: 2x servers with 32 GB RAM each (Active-Active cluster)

With this configuration, the cluster handles 800 peak concurrent sessions on one node alone. Adding a third node provides additional headroom for growth and maintenance windows.

This mirrors the setup used in the ongoing POC at a leading Israeli insurance group: 2x 32 GB nodes serving approximately 800 peak concurrent sessions across 5,000 total users.

Interactive Calculator

Use the interactive sizing calculator at /imterm/calculator.html to compute safe session counts for your specific hardware. Enter your server RAM, OS type, number of nodes, and concurrency ratio - the calculator applies the formula above and shows the recommended max_sessions value to set in config.yaml.

Enforcing Limits in config.yaml

Set max_sessions in config.yaml to the safe session count for your hardware. IMTerm enforces this limit at the session accept layer - new connection attempts beyond the limit are rejected with HTTP 503.

# config.yaml
max_sessions: 700    # safe sessions for a 32 GB Linux node

Setting max_sessions: 0 disables the limit (not recommended for production). Your license also enforces a separate seat cap that cannot be overridden in config.

Health Endpoint and Capacity Signals

The /api/health endpoint reports the current session count and capacity percentage. Load balancers and monitoring systems can poll this endpoint to make routing decisions.

curl https://imterm.corp.com/api/health

Example response when the node is healthy and has capacity:

{
  "status": "ok",
  "sessions": 342,
  "max_sessions": 700,
  "capacity_pct": 48.9,
  "node_state": "ONLINE"
}

When the node is full (sessions >= max_sessions), the endpoint returns HTTP 503:

{
  "status": "full",
  "sessions": 700,
  "max_sessions": 700,
  "capacity_pct": 100.0,
  "node_state": "ONLINE"
}

Configure your load balancer to remove a node from the rotation when it returns HTTP 503 from /api/health. New users will be directed to nodes with available capacity. Users already connected to the full node continue their sessions unaffected.

Audit Events

Monitor IMTE7210W frequency in your SIEM. A sustained rate of capacity refusals indicates the cluster needs additional nodes or higher-RAM hardware.