There are many free  and cheap client programs that claim they can stress your RADIUS server. Almost all free software claiming this  is doing nothing like this. Even some $$ will fail to provide the real answer.

But do they?

Well no. The typical methodology is fundamentally flawed. They tell you how fast client loader sends packet but nothing about the server’s response time. You are looking at the wrong numbers.

How do these programs work?

Basically they act as either a single client sending packets out and waiting for responses, if more sophisticated they are threaded clients doing the same thing,  What’s the problem with that?

Why Wait?

What is the load test software doing while it’s waiting for a reply? Nothing. It sure isn’t sending packets during that time. They are merely testing frequent connectivity. This is not the same as the RADIUS server’s response time at peak load.

Running client load tests on the Server

Running the client load test on the same machine as the RADIUS server means the client loader, if in any way effective, is drawing from the same resources needed by the server.

What are you really looking for?

The maximum speed of the server – how many packets can it handle per second. Why would you ask the client side to tell you this when the server already knows how many packets it is processing?

We offer you  a test that can load your server as fast as either the tester can run. The client load test has multiple threads, does authentication an accounting. It can run in the capacity of one of those connectivity.

Or it can run close to the perfect load tester. How? It certainty doesn’t have to wait for replies. Set the wait time down to a millisecond so there is onl;y a tiny delay between sending packets. Who cares if the client gets an answer – the test is loading the server. We offer than in our programing examples directory under ‘clientload’. It too cannot produce client instantaneously taking a millisecond or so to reset the client.

It is a multi-threaded packet client either running authentication or accounting packets or a mixture of both. Most importantly you can set the timeout to just one millisecond effectively causing the client to quite upon sending and immediately starts sending a new packet. Why wait for the response – the server will send the response if the client is listening or not. That’s what UDP is all about.

Where are the results?

They are on the server. Every reasonable server is either running SNMP as a server or internally and at the very least they have a packet counters of some sort. With the client loader(s) running at full tilt the server will try to answer as many packets as it can over the duration or count you  choose.

Check the server’s counters when the test concludes and make your own assessment of the server speed at the server, not at the client.

It’s that simple. Don’t rely on the client to tell you what the server is doing because it will only report on how well it performs, not the server.

Disappointing results?

In our server the packet code path is fixed for a well formed authentication or accounting packet. You will want to get rid of the slowness in your code.

You can surround your code with if (false) { … } and then load the server. If the results have not improved call us. The next step might be profiling your code since that’s the only variable left. This is generally the downfall of all RADIUS servers – slow external code, or relying on slow inefficient databases, forking to other programs, poorly thought out accounting systems.

In all cases the accounting side of the server is the busiest side of the server usually relying on databases and external code to handle the flood of accounting packets.

A Case in Point:

An accounting server in a highly populated country was crashing after running for a period of time. A company wanted to know how.

Accounting is the most intensive part of RADIUS operations since it involves high intensity use of a database inserting and updating records constantly. Databases are notoriously slow compared to any busy RADIUS server.

Our server merely sat in as a proxy server ferrying accounting packets to any from the main accounting server. It tracked the response time for each pair of packets.

The result was a flat line of round trip timings for a while which slowly ramped up into a perfect power curve until the accounting server failed. Once the accounting server reached a critical point where service had slowed down enough that people were getting impatient with log in times they would repeat their log in attempts. Once the curve was seen along with the analysis of the discrete data captured the company realized the database what overwhelmed.

The number of people testing this server was en excess of a hundred thousand. Only in some countries is it possible to really stress a RADIUS during “light'”use.