RADIUS throughput and scaling
Benchmarking results below can be used to determine the type of server (or servers) needed to support the peak authentication-events per minute your environment is being designed to accommodate.
The Okta RADIUS Server Agent has been benchmarked on an AWS t2.medium instance (see https://aws.amazon.com/ec2/instance-types/), which represents a modest baseline of hardware specs (2 vCPU cores, 4GiB memory). The benchmark was performed at Okta RADIUS Server Agent default settings, which are typically suitable for most customers.
These benchmarks were run using JMeter to simulate a real end-user login flow using the Web VPN login (browser) > Cisco ASA > RADIUS Server Agent > Okta.
System specification: Amazon EC2 t2.medium (2 vCPU, 4 GiB memory), Windows Server 2012, Okta RADIUS Server Agent v.2.7.0 (thread count: 15, connection pool size: 20)
|Arrival Rate (per second)
|Error rate % (Primary/MFA)
|CPU % (peak)
|Memory Use MB (peak)
|Okta Verify w/ Push
|0 / 0
|0 / 0
The RADIUS Agent has a pool of worker threads and accepts incoming requests using a queue. Because the throughput depends on a lot of factors both internal and external to the agent (how many authentication threads are in the worker pool, how long each request to the Okta service takes, how long an end-user takes to respond to a push MFA notification, and so on), actual results can vary. It is important to test throughput in your own deployment and tune the agent according to how it performs in your own environment.
The RADIUS Agent connects to the Okta Service through REST APIs, and is subject to the same rate limits as any other HTTP client. If your capacity requirements are high, you can horizontally scale by adding additional RADIUS agents and spreading load between them, but note that they will each count independently against your total allowed API calls on the Okta Service. See API rate limits for more information. If the RADIUS Agent is rate limited, it will return an ACCESS-REJECT response for those requests.