[RADIATOR] A few tips on performance and high availabilty

[Anders Bandholm]

Hi list!

We have been running Radiator for several purposes for around 5 years,
and I would like to share a few tricks that we have learned...


Memcached
---------

Memcached is distributed cache, with a simple Perl-api. We run an instance
of memcached on each Radius-server. We use it for several things:

  * We use it in a PostAuthHook for rejecting users with too many login
    failures (to prevent brute-force password guessing)

  * We cache certain SOAP-calls. Since Radiator is single-threaded, fast
    answers from backends is imperative as you probably know. We use
    memcached in a "defensive" way: We always make the SOAP-call first,
    but with a low timeout (0.1 sec) If the call times out, we use the
    cache - if not we save the result to the cache.

  * we have started a service for our customers (Danish schools) where
    they get alerts by email when user up- or download exceeds certain
    thresholds. This is handled by summing up bytes from accounting
    records in a PostProcessingHook. The counters for each user is kept
    in memcached.

It seems to me that memcached is a perfect companion for Radiator!

Memcached is of course not a database, and if you shut down one of
the memcached instances you will lose part of your cache. But for the
purposes above it works very well.

The Perl module is Cache::Memcached.

If you run Linux memcached is probably packaged for you - on Debian/Ubuntu
you need packages like these:

    memcached
    libcache-memcached-perl
    libmemcached-tools


Two other tricks
----------------

 1) We have started using Gearman to make it possible for the main radii
    to offload certain slow things to other servers. As explained above
    our radii keep track of user up/downloads through acct-records, and
    when a certain limit is reached we send email alerts to the relevant
    admin. But we don't want Radiator itself to send the email - we submit
    a job through Gearman (Perl: Gearman::Client and Gearman::Worker)
    This is a very promising technology and I expect we will use it more
    in the future.

 2) Simple trick - probably used by many of you: We have the client list
    in an Oracle database, but since the database is sometimes down
    for maintenance, we generate static file-based client-lists every
    10 minutes instead, and reload Radiator when they change. If Oracle
    is down, Radiator does not suffer. (The 10 minutes interval is
    overkill for most installations ;-)


Cheers,
Anders
-- 
Anders Bandholm, UNI-C, Aarhus
  Anders.Bandholm at uni-c.dk       (+45) 8937-6645       Fax: (+45) 8937-6677
  PGP: id=0x0DD38396; fp=9FDE 3B13 6CA3 BD03 7BF1  7062 E694 D295 0DD3 8396