rlm_rest performance / thread usage
We make a billing system which has a JSON API which allows our customers to hook in FreeRADIUS servers to provide RADIUS and DHCP. Up to now we have always used rlm_perl along with a perl script using the JSON and HTTP perl modules to generate the JSON and get it to and from our API. Recently, I have done a few experiments using the rlm_rest module in place of rlm_perl, and I have been very impressed. It is easy to configure and it provides a simpler solution for us, in that it renders the perl script unnecessary. I would like to ask whether there is likely to be any performance difference beteween these two solutions. rlm_perl is performing well for us and as I understand it runs in a multithreaded mode whereby multple perl instances can be created by multiple server threads. I would like to ask whether the rlm_rest module is likely to offer as good as or better performance as we are currently getting with rlm_perl. Also, I would like to understand whether it is necessary to configure multiple instances of rlm_rest and put them for example in a load_balance section in order to get the best performance. Ben Thompson
On Sep 12, 2017, at 7:41 AM, Бенджамин Томпсон <b.thompson@latera.ru> wrote:
I would like to ask whether there is likely to be any performance difference beteween these two solutions. rlm_perl is performing well for us and as I understand it runs in a multithreaded mode whereby multple perl instances can be created by multiple server threads. I would like to ask whether the rlm_rest module is likely to offer as good as or better performance as we are currently getting with rlm_perl.
I would say that the REST module has better performance than Perl. For the simple reason that it's doing less work. i.e. it's *only* doing REST. The Perl module has an entire Perl interpreter, overhead, etc.
Also, I would like to understand whether it is necessary to configure multiple instances of rlm_rest and put them for example in a load_balance section in order to get the best performance.
It shouldn't be necessary. You should only use a load-balance section if you need to load-balance requests across multiple back-ends. i.e. when the back-end is slower than FreeRADIUS. Alan DeKok.
On 12 Sep 2017, at 19:18, Alan DeKok <aland@deployingradius.com> wrote:
On Sep 12, 2017, at 7:41 AM, Бенджамин Томпсон <b.thompson@latera.ru> wrote:
I would like to ask whether there is likely to be any performance difference beteween these two solutions. rlm_perl is performing well for us and as I understand it runs in a multithreaded mode whereby multple perl instances can be created by multiple server threads. I would like to ask whether the rlm_rest module is likely to offer as good as or better performance as we are currently getting with rlm_perl.
I would say that the REST module has better performance than Perl. For the simple reason that it's doing less work.
It also does things right out of the box, like connection caching. With Perl and Python that was always a bit of a pain because of needing data to persist between requests.
i.e. it's *only* doing REST. The Perl module has an entire Perl interpreter, overhead, etc.
Even faster in v4.0.x as we've switched to the async libcurl interface. -Arran
2017-09-13 4:24 GMT+03:00 Arran Cudbard-Bell <a.cudbardb@freeradius.org>:
On 12 Sep 2017, at 19:18, Alan DeKok <aland@deployingradius.com> wrote:
On Sep 12, 2017, at 7:41 AM, Бенджамин Томпсон <b.thompson@latera.ru> wrote:
I would like to ask whether there is likely to be any performance difference beteween these two solutions. rlm_perl is performing well for us and as I understand it runs in a multithreaded mode whereby multple perl instances can be created by multiple server threads. I would like to ask whether the rlm_rest module is likely to offer as good as or better performance as we are currently getting with rlm_perl.
I would say that the REST module has better performance than Perl. For the simple reason that it's doing less work.
It also does things right out of the box, like connection caching. With Perl and Python that was always a bit of a pain because of needing data to persist between requests.
i.e. it's *only* doing REST. The Perl module has an entire Perl interpreter, overhead, etc.
Even faster in v4.0.x as we've switched to the async libcurl interface.
-Arran
Thanks Alan and Arran for your replies.
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Бенджамин Томпсон