[RADIATOR] A few tips on performance and high availabilty

[Michael]

This memcache sounds pretty nice.  I do experience many pppoe logins 
where a router will constantly attempt to login which is fine at a slow 
rate.  Some router (usually Dlink) must be defective as they sometimes 
attempt to login WAY TOO often.  My personal record i've seen  is about 
12 times a second.  This means a little over 1 million rows in a failure 
sql table per day.  I have so far combated this issue by instead of 
logging every failure, i use an sql table with a unique index key 
between the username, a month/day value, and message, then use an 
"INSERT INTO table .....  ON DUPLICATE KEY UPDATE hits=hits+1.  It works 
quite nicely.  This reduces these 1 million rows PER DAY down to just 1 
row per day and counts the number of times it happens in a given day.  
28/30/31 rows for the month.  Very effective.

I also have routers that seems to login, logout, login, logout 
successfully all day long.  This must be defective routers, but i'm not 
interested in a REACTIVE solution of calling these people and telling 
them they need to trash that router. I'm more interested in PROACTIVE 
solutions to battle this.

Just a quick glance right now in my success log, i've got 2 people, 12 
thousand, and 16 thousand logins so far for just today.  And this will 
be every day.  These are SUCCESS.  so these routers are logging in, 
logging out constantly. And i'm only 11 hours into this day.

Failures, 127 thousand for 1 user again just for today.  And i'm only 11 
hours into this day.


The login attempts though, still of course cause many unneeded sql 
queries for the authentication.  This memcache sounds interesting.  Do 
you have a quick description of usage, or a link describing how to 
implement it into radiator?


Thanks



On 03/12/12 11:17 AM, Anders Bandholm wrote:
> 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