(RADIATOR) threading

Tariq Rashid tariq.rashid at uk.easynet.net
Tue Oct 26 08:07:28 CDT 2004


disagree - the granularity of perl/python languages is not as fine as to
allow much benefit. this is acknowledged by the perl and python developers.
the locks are too big!

for serious "concurrent" work using these languages, you are better of using
state-tables and event-driven asynchronous handling. 

so for perl/python your best bet is to use a proxy whoch forwards to
multiple radiator instances (prefereable on different machines). and in this
case i recommend using a C-based proxy as my own experiments have found that
the perl one at radiatr version 3.8 wasn't that great with latency.

but there are overwhelming advantages to using radiator which you're
familiar with already - such as its very powerful and extreme customisation.


tariq



-----Original Message-----
From: Guðbjörn S. Hreinsson [mailto:gsh at centrum.is]
Sent: 26 October 2004 12:19
To: 'Andy De Petter'; 'Hugh Irvine'
Cc: radiator at open.com.au
Subject: RE: (RADIATOR) threading




> PS: I don't agree in the fact that you say that threading won't
> necessarily improve anything. Threads tend to be much faster to create,
> and use less memory than forked processes. I agree, perl doesn't fully
> take advantage of this yet, but they will once - and we should better be
> ready for it. ;)

I would have to agree with this, but not only from performance perspective. 
radiator today is a single pipeline with multiple stopovers (depending 
on config), all incoming packets have to wait for the processing of the 
preceding packet. If a single packet gets processed slowly for some reason 
all packets have to wait. You can build multiple instances (poor man's 
threading?) per accounting and authentication/authorization and multiple 
instances per NASes and/or NAS groups but this tends to complicate things 
and make management more difficult. Of course you need to maintain the 
performance level of all backends but perusing thread models can only 
give a more reliable, higher performing and better resource performance 
than a single process model. 

Just my ISK 0.2
-GSH


--
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.

--
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.


More information about the radiator mailing list