Tariq Rashid <[EMAIL PROTECTED]> wrote: > throttle them - ie, if the request rate is say 80/s or less then that is > fine. if the requests come in faster, then the "smoothing" buffer would > store them in a queue and then release them at a rate no quicker than the > chosen rate, say 80/s.
See src/main/threads.c The server stores *all* incoming requests in a queue, and the threads pick up a request when they're done processing earlier ones. So to that extent, it's already doing what you want. > i am aware that this just forms anothe queue but it seems to me that this > might mitigate the problem where it is the high "rate" which knocks the > servers out (might have nothing to do with the freeradius server, maybe the > underlying OS, various freebsd 4.x), not the large queues. note that my > earlier tests showed that slow queue processing were the limiting factor for > another radius server i tested (not freeradius). The slow processing in FreeRADIUS is most likely caused by the simple backlog of requests. If it can process 100 requests/s, and it gets 500 in one second, then it will take 5 seconds to respond to all of those requests. > i'm also aware that if teh smoothing queue is full then requests can be > dropped - but it seems that at the moment this is not happening before the > server gets "knocked out". The server *does* discard re-transmits from the NAS when the original packet is still in the queue. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
