RADIUS throughput and scaling benchmarks
You can use benchmarking results to determine the type of servers you need to support the peak authentication events per minute that your environment can accommodate.
The Okta RADIUS Server Agent has been benchmarked on an AWS t2.medium instance. This represents a modest baseline of hardware specifications. These benchmarks were run using JMeter to simulate a real user sign-in flow using . They evaluated the default Okta RADIUS Server Agent settings, which are suitable for most customers. See Amazon EC2 General Purpose Instances.
The RADIUS Agent has a pool of worker threads and accepts incoming requests using a queue. Actual results may vary because the throughput depends on many factors internal and external to the agent, such as these examples:
- The number of authentication threads in the worker pool
- How long the Okta Service takes to process each request
- How long a user takes to respond to a push MFA notification
Test the throughput in your own deployment and tune the agent according to how it performs.
System specification
- Amazon EC2 t2.medium
- 2 vCPU
- 4 GB of memory
- Microsoft Windows Server 2012
- Okta RADIUS Server Agent version 2.7.0
- Thread count: 15
- Connection pool size: 20
Results
|
Arrival rate (per second) |
Factor |
Error rate % (primary/MFA) |
CPU % (peak) |
Memory use megabytes (peak) |
| 6.5 | Okta Verify w/ Push | 0 / 0 | 3 | 20 |
| 25 | Security Question | 0 / 0 | 3 | 20 |
The RADIUS Agent connects to the Okta Service through REST APIs. It's subject to the same rate limits as any other HTTP client. If your capacity requirements are high, you can horizontally scale by adding more RADIUS agents and spreading the load between them. However, they each count independently against your total allowed API calls on the Okta Service. If the RADIUS Agent is rate limited, it returns an ACCESS-REJECT response for those requests. See API rate limits.