(RADIATOR) considerations for very high volume proxying and post-processing

[Tariq Rashid]

hi all, 

i'd be grateful for comments if you have experience in using Radiator for
very high volume proxying (acct and auth), and post-processing of proxy
responces. 

scenario:
	* must scale to about 300 requests per second at peak peak times
	* proxy radiator forwards requests to target radius platforms based
on domain
	* accounting is also forwarded (best effort is acceptable)
	* availability and robustness - a misbehaving target radius must not
affect normal service
	* returned reponses from the proxy targets are then cleansed
(attribute filter) and may have
		additional attributes appended

so the proxy here is the point which needs consideration, the proxy target
radius servers are numerous and can handle load (more can be added as
required).

so regarding the proxy, questions to think about include:

	* hardware configuration
		- dual cpu?
		- separate pure proxy from post-processing onto different
hardware?

	* best OS for such work
		- low latency? ability to handle many open connections?
network performance?
		- radiator isn't threaded so thread performance does doesn't
matter?

	* best radiator configurations
		- single instance? multiple instances for pure proxcy and
cleansing?
		- how to handle more than 256 pending proxy responces?
		- proxy is a state-table not threads, easy to control table
expiry times?

the radius protocol determines 8bits for the uid for a proxy request. this
means that a radius proxy can't have more than 256 pending radius requests,
in theory. in reality i am sure that this can't be an issue. by what method
do high volume radius proxies manage this? not all hardware NASes support
extended UIDs.

comments, warnings and experiences welcomed gratefully,

tariq

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.