Le 03/03/2015 11:01, "RESTOUX, Loïc" wrote :
If it's a scheduler problem, should we not see that all threads are active, but blocked somewhere ?
Another thoughts about this: a network analysis seems to show that the bottleneck is not in post-proxy handling, but upstream. We know that radperf is sending as much requests as we told him (with -p 500 argument), but the rate of outgoing proxied requests is far lower. See the graphs above: - rlm_lrs invoked in pre-proxy section: http://postimg.org/image/nvga69qwx/ - rlm_lrs invoked in post-proxy section: http://postimg.org/image/oyjo6mjgh/ So, is it possible that FreeRadius slows down the proxied requests sent to the remote radius, for instance in order to be sure to have always enough available threads to deal with the responses ? Note that our max_outstanding parameter is set to 4096. Should we care of other parameters in the proxy section ? Regards, -- LRS This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.