Scalability notes for the WiKID Strong Authentication server

admin
2015-10-26T16:26:00+00:00

Large two-factor authentication deployments are becoming more and more common these days as enterprises deploy it to more and more employees . We're also seeing more SaaS providers needing to meet regulations such as HIPAA and PCI. These enterprises have large user bases and need scalable, reliable, affordable two-factor authentication. We have the affordable part covered (you can see our pricing online) and we are highly incented to provide reliable software thanks to our annual subscription license. But how scalable is WiKID?

We have had a stress tester for some time. We use it along with our quick-setup config option to quickly build and test new releases. We decided to publish some results to show how well WiKID can scale. The first thing to know is that you can segment users across WiKID boxes without their knowledge or any impact on users. Second, we are testing transactions/authentication per time period and doing a lot, because we want to stress the system. You need to know the authentication per minute that you do to know how many WiKID servers you need.

The stress tester registers a number of users and then tests authentications using RADIUS. We throw a number of round on the stress tester. The WiKID virtual servers use our minimum recommended set up of 2 gigs of RAM and 1 CPU. They are configured for replication, primary and secondary. The host is a modest server with plenty of RAM and 1 CPU with 8 cores. The tester runs on the host and the servers are in VirtualBox.

Transactions | Tx/Minute | Tx/Hour
1,000 | 342.95 | 20,577.07
1,000 | 394.83 | 23,689.67
1,000 | 371.29 | 22,277.23
1,000 | 379.08 | 22,744.93
| Average | 22,322.23

The tester starts out registering a bunch of users, then performs radius authentications for those testers. Here it is with 10,000 transactions:

Transactions | TX/Minute | Tx/Hour
10,000 | 408.75 | 24,525.07
10,000 | 408.11 | 24,486.40
10,000 | 409.39 | 24,581.30
| Average | 24,530.92

24,000 transactions per hour is a very decent through put for a single small server.

Next, I set the logs to go to syslog instead of to the database. This means that they are not available in the WiKIDAdmin web UI, but they would go into your SIEM (you can set them to go to both, but you wouldn't see any speed improvement.

Transactions | Tx/Minute | Tx/Hour
1,000 | 580.78 | 34,846.58
1,000 | 714.37 | 42,862.25
1,000 | 769.36 | 46,161.54
1,000 | 800.38 | 48,023.05
| Average | 45,682.28

That's pretty impressive. 45,000 authentications per hour.

This gives you an idea of what kind of peak performance WiKID can handle. This last 1,000 transaction test took less than 2 minutes. We're going on the record as saying that WiKID is secure, reliable, and highly scalable.