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.bandh...@uni-c.dk (+45) 8937-6645 Fax: (+45) 8937-6677 PGP: id=0x0DD38396; fp=9FDE 3B13 6CA3 BD03 7BF1 7062 E694 D295 0DD3 8396 _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator