Skip to main content

Scalability notes for the WiKID Strong Authentication server

Posted by: admin 9 years ago

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.

TransactionsTx/MinuteTx/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:

TransactionsTX/MinuteTx/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. 

TransactionsTx/MinuteTx/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.

Current rating: 2.6

Recent Posts

Archive

2024
2022
2021
2019
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008

Categories

Tags

Authors

Feeds

RSS / Atom