Weird issue - threads bottleneck in post-proxy section

"RESTOUX, Loïc" loic.restoux at capgemini.com
Mon Mar 2 14:34:14 CET 2015


Hi Alan,

Le 27/02/2015 14:35, Alan DeKok a écrit :
> Some modules cannot be multi-threaded. The server implements mutexes
> to be sure that the modules are used only by one thread. If that
> module is used, *and* it takes a long time to do it’s work, then all
> threads will block on that module.

We agree. But reading the source code, rlm_rest is multi-thread 
compliant (RLM_TYPE_THREAD_SAFE). So we're assuming that there is no 
mutex for the rest module.

> And the rest module doesn’t behave any differently in post-proxy.

The weird thing is that if we move the use of rlm_rest in another 
section like pre-proxy, there is no blocking issue any more.

> What other modules are you running in post-proxy?

At that time, this is the only one, precisely in order to analyse the 
bottleneck issue.

Let's see some facts:
- We have a remote radius server that always answer immediately with an 
Access-Accept.
- We have a REST server that delivers a JSON response in around 100 ms.
- Our freeradius is configured to proxy requests to the remote radius 
server and to call the REST server before or after the request to the 
remote radius server.

We used radperf for benchmark (-p 500). The results:
- No REST request at all => freeradius handles 3800 requests per sec 
approximately.
- if the REST server is called in pre-proxy => 1100 r/s. All the threads 
of the pool are active.
- if the REST server is called in post-proxy => between 70and 150 r/s 
with a lot of variation between our tests. Less than half of available 
threads are active.

Thank you for your help,

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



More information about the Freeradius-Users mailing list