rlm_perl and Threaded Perl??

[Fajar A. Nugraha]

On Tue, Feb 14, 2012 at 7:57 PM, Simon Earthrowl <searthrowl at eseye.com> wrote:
> Hardware: based on ESX host:
>     4 core 2.1GHz processor (have 24 cores to play with)
>     8GB Memory (have more as needed)

err ... that's not really much these days.

> Limitations so far:
>     4 million dial-in potential users (16 million gets a bit slow - so
> looking for other improvements)

It's way overkill for FR with files backend. But once you include any
kind of db or external backend (e.g. mysql, perl, whatever) then those
system can quickly becomes the bottleneck. In the case of mysql, the
bottleneck is usually disk IOPS.

>     In bound transaction rate (sustained mix of 1:1.5 of radius
> authentication:Radius accounting) 2048

2048 per what? seconds?

>     Response time (so far and improving) < 500mS (current gains are from
> reworking MySQL data tables, structures, and indexes)

That'd still mean you have a bottleneck somewhere.

IIRC on a simple FR-mysql setup, I got several thousand auth+acct/sec,
and that's with a pretty low max thread count (the 200-something I
mentioned earlier. It's low compared to yours).

>
> CPU utilisation is still low (as reported by VSphere) ~15% ie MySQL is
> running well, and so is FR. Packet loss increases to 10% 2.5K
> transactions/sec.

is this during your load test?

If yes, then there's no reason to use 2048 threads. Really. Just lower them.

> I've wanted to limit the number of threads, as if the activeMQ server fails,
> I don't want radius to fail (users shouldn't be penalised because of poor
> systems management/setup). It's all a bit too open ended for me to feel
> comfortable with this as a solution as it stands.

It's kinda complicated. Short version is if you use your external
system only for acct, then using something similar to
sites-available/buffered-sql should do the trick (i.e. log to detail
file first, process later). But if you also need it for auth, then it
gets compicated. Possible (especially if you only consider the case
when the external system is dead), but complicated (especially if you
consider the case when the external system simply becomes too slow)

> My feeling is that I've yet to unleash the real power of FR; but it's far

It's pretty flexible. The hardest part is defining your policies. For
example: how would you want FR to detect if your external system
fails? How long must it wait?

> from obvious to me, as to how to improve MySQL performance with FR. Reading
> others: dumping MySQL (albeit in a MySQL configuration -> local file +
> reload) way seems the next step.

mysql can perform just fine on super-busy implementation, IF you have
the skills of a competent dba (or have someone with that skill helping
you).

-- 
Fajar