Skip to main content

Scalability notes for the WiKID Strong Authentication server


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.

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:

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. 

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.

Current rating: 5


There are currently no comments

New Comment


required (not published)


Recent Posts







RSS / Atom