Radiator sizing

Radiator sizing

Radiator capacity depends mainly on the work performed for each transaction. The CPU estimates in this guide use RADIUS packets as the reference workload. Integrations add work and latency to each transaction. Password hashing adds CPU cost.

For deployments that store operational data in RadiatorDB, see RadiatorDB sizing.

CPU and memory sizing

These estimates map the required transaction rate to CPU and memory for one Radiator instance. They include operating headroom above the measured CPU and memory use.

• Reference CPU performance: 4,750 sysbench cpu events per second for each CPU.

The in-memory figures apply when Radiator uses in-memory structures for authentication and authorization, writes authentication logs to local disk, and makes no integration queries.

Integration latency and capacity can reduce the end-to-end transaction rate and increasing memory usage. The memory usage values here are very high and typical normal operations all run under a quarter of memory in the table. This is defense against hostile network situations or plain networking hickups which will add to in flight requests.

Radius and other protocols do not have much impact on performance if encryption is used. Typical TLS overhead is around 10% in compute and memory.

Storage sizing

Log storage depends on the number of rows, row size, and retention. The table uses these example workloads and a planning average of 1 KiB per uncompressed row. Normal entries can be smaller, but errors can produce substantially longer entries with diagnostic details.

• Network access creates one row for each successful or failed login. The example assumes 1,000,000 login attempts per day.
• Network accounting creates one row per active session every 15 minutes. The example assumes an average of 100,000 active sessions, or 9,600,000 rows per day.

The examples assume one log row for each request.

Scale these values by the actual rows per day and average row size. The compressed estimate assumes daily log rotation, 30-day retention, compression at 7 days, and a compressed size of 15%.

Designing a deployment

Additional sizing factors

Account for these factors when applying the CPU and memory estimates:

• Password hashing uses CPU for each authentication. Size from the production hash algorithm and its settings.
• High request rates require enough parallel connections
• A single Radiator instance can use more than 8 CPUs. It is worth considering to distribute to multiple instances than make one or two really big ones.
• Memory use can remain low during normal operation, but buffers can grow rapidly when network disruptions delay processing. Reserve memory for these backlog peaks.