(RADIATOR) 190 second back-off delay after spikes - between ReWrite username and using realm

Tariq Rashid tariq.rashid at uk.easynet.net
Thu Apr 29 04:07:00 CDT 2004



I've narrowed down the cause of this delays in the radiator resonce which on my systems occur for abour 190 seconds after a spike in the request rate. 

	* The radiator logs keep showing debug output for global "ReWrote username"
	  throuoghout the silent response periods.
	  This indicates that radiator is still pickign requests out of a queue.

	* The delays appear next, at the "checking realm" step. During the silent no
	   response periods there is no "checking realm". 

This is non-obvious to me because i would have though that the backend LDAP or SQL would have been the bottlneck but this indicates otherwise. We only implement post-search-hooks, so there is no user-supplied sql/ldap or other backend between the above two stages. And as far as i know, raidator itself doesn't do any backend queries untuil at least after the "checking realm".

Am I barking up the wrong tree?

The above has been verified for different spikes over different days from different weeks.

Tariq



-----Original Message-----
From: Tariq Rashid 
Sent: 27 April 2004 11:11
To: radiator at open.com.au
Subject: (RADIATOR) 190 back-off delay after a peak inrequest rate -
cause?



i've been looking at radiator "detail file" logs ... and especially at periods when the request rate spikes.

i've found that after a spike (from the normal 1/2 requests per second per loadbalanced radius server at 85% of the time) up to over 10 requests per second,  there appears to be a 190 seconds delay before further requests are processed.

what could this be? the configuration files don't specifically configure a 190 (or more likely 180 = 3*60) second back-off from another backend service?

does anyone have any experience of this? would it be the default LDAP or MySQL back-off time?

or perhaps its a lower level TCP or UDP queue timeout?

if i can narrow down to what service is failing, if it is a back-off, then i can then look at beefing up that backend...

thanks in advance

tariq rashid

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