[RADIATOR] new ServerFarm support in Radiator 4.3.1 patches

[Hugh Irvine]

Hello Everyone -

I have recently been testing the new "ServerFarm" support (BETA) in  
the latest Radiator 4.3.1 patch set, with interesting results.

The latest Radiator 4.3.1 patch set contains BETA support for a new  
"ServerFarm n" configuration parameter which is designed to implement  
a controlled form of multi-threading (on *NIX platforms only).

The addition of "ServerFarm 5" for example will cause radiusd to spawn  
5 child processes, each of which will listen on the AuthPort and/or  
AcctPort as defined in the configuration file.

Each child process will then read from the same port and each will  
process RADIUS requests in parallel with the others.

This type of configuration is useful in two particular situations.

The first is for a "front-end" load-balancer type of Radiator instance  
which is distributing RADIUS requests across multiple "back-end"  
processes. In this type of scenario it is usually the "front-end"  
instance that becomes the bottleneck, and hence benefits from multiple  
child processes. Note that either AuthBy HASHBALANCE or AuthBy  
EAPBALANCE will be required for EAP request streams.

The second is for a "back-end" type of Radiator instance that is  
accessing an SQL (or LDAP) database. In this type of scenario it is  
usually the SQL database access that becomes the bottleneck, and  
multiple parallel SQL connections to the database can potentially  
improve overall performance.

Today's testing involved Radiator 4.3.1 (plus the latest patch set)  
and a MySQL 4.1.15 database on Solaris 10 running on a T5220 multi- 
core machine.

A single instance of Radiator appeared to be able to process a maximum  
of approximately 100 requests per second.

Three separate machines running "radpwtst" each sent 3000 requests,  
for a total of 9000 requests and an overall processing time of  
approximately 90 seconds.

Adding "ServerFarm 3" to the Radiator configuration file caused 3  
child processes to be spawned, and the overall processing time dropped  
to approximately 40 seconds.

Each child process handled approximately 100 requests per second.

Adding "ServerFarm 8" to the Radiator configuration file caused 8  
child processes to be spawned, and the overall processing time was  
also approximately 40 seconds.

Each child process handled between 30 and 50 requests per second.

These are preliminary results and are by no means definitive, nor was  
the test procedure indicative of real-world RADIUS request processing,  
however the results are encouraging.

Interested Radiator customers can do some lab testing of their own and  
we are most interested in your results.

See "goodies/serverfarm.cfg" for an example configuration file.

As mentioned above, this is BETA release software at this stage and  
should not yet be put into full production.

Feedback please - all comments welcome.

regards

Hugh



NB:

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?
Have you checked the RadiusExpert wiki:
http://www.open.com.au/wiki/index.php/Main_Page

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.