rlm_perl does not honor start_servers?
Hello! I've got latest 3.0.11 FreeRADIUS and Perl authorization module under rlm_perl. The server is relatively highly loaded (around 1000 access-requests per sec). And although i have "start_servers = 256" and "min_spare_servers = 256" in the thread pool configuration, FreeRADIUS does not initialize those threads until the requests start to hit the daemon. After some requests in parallel it spawns all required 256 threads and then this number stays constant. The problem is that the thread creation in rlm_perl seems to be quite expensive timewise (or i may be doing something wrong?). It is clearly seen by testing with radclient - after daemon restart it is capable of only 30 req/s. Then, when all the threads come alive - it goes up to 1k req/s and more. So unless i warm up the server with a few thousand test queries to create all threads - it gets overwhelmed for several minutes when the real load shows up, which causes a lot of warnings in the logs and massive retransmits from NASes (there are about 900 of them with lots of clients each), which is nasty. So the question is - this behavior is expected? I can, of course, warm up server after each restart but it seems irrational for me. Thanks!
On Apr 1, 2016, at 9:53 AM, Igor Novgorodov <igor@novg.net> wrote:
I've got latest 3.0.11 FreeRADIUS and Perl authorization module under rlm_perl. The server is relatively highly loaded (around 1000 access-requests per sec).
And although i have "start_servers = 256" and "min_spare_servers = 256" in the thread pool configuration, FreeRADIUS does not initialize those threads until the requests start to hit the daemon.
FreeRADIUS starts all 256 threads. The "spare" threads are created as needed.
After some requests in parallel it spawns all required 256 threads and then this number stays constant.
The problem is that the thread creation in rlm_perl seems to be quite expensive timewise (or i may be doing something wrong?).
Thread creation in Perl is very different than thread creation in the server core. The server starts 256 threads. BUT the Perl module still has to initialize any thread-specific context. That doesn't happen until the module is called.
It is clearly seen by testing with radclient - after daemon restart it is capable of only 30 req/s. Then, when all the threads come alive - it goes up to 1k req/s and more.
That sounds about right.
So unless i warm up the server with a few thousand test queries to create all threads - it gets overwhelmed for several minutes when the real load shows up, which causes a lot of warnings in the logs and massive retransmits from NASes (there are about 900 of them with lots of clients each), which is nasty.
Having the server initialize Perl 256 times won't help. It will just push the delay *slightly* earlier. i.e. the server will either block and do nothing for a long time while it's initializing 256 Perl threads, or it will slowly process packets while it's initializing the Perl threads. Either choice isn't perfect. And there's no real way around it. If Perl is slow to initialize... then it's slow to initialize. There's no magic you can do to make it faster.
So the question is - this behavior is expected? I can, of course, warm up server after each restart but it seems irrational for me.
Then you don't understand how computers work. My guess here is that the problem isn't starting up 256 Perl threads, the problem is that your Perl code is tens of thousands of lines long. And compiling *that* is taking forever. So the solution is to not use complex Perl scripts. Alan DeKok.
On 01.04.2016 17:00, Alan DeKok wrote:
On Apr 1, 2016, at 9:53 AM, Igor Novgorodov <igor@novg.net> wrote:
I've got latest 3.0.11 FreeRADIUS and Perl authorization module under rlm_perl. The server is relatively highly loaded (around 1000 access-requests per sec).
And although i have "start_servers = 256" and "min_spare_servers = 256" in the thread pool configuration, FreeRADIUS does not initialize those threads until the requests start to hit the daemon. FreeRADIUS starts all 256 threads. The "spare" threads are created as needed.
After some requests in parallel it spawns all required 256 threads and then this number stays constant.
The problem is that the thread creation in rlm_perl seems to be quite expensive timewise (or i may be doing something wrong?). Thread creation in Perl is very different than thread creation in the server core. The server starts 256 threads. BUT the Perl module still has to initialize any thread-specific context. That doesn't happen until the module is called. Ok, so there's no way to make it to initialize Perl's thread stuff when the server core threads are spawned?
It is clearly seen by testing with radclient - after daemon restart it is capable of only 30 req/s. Then, when all the threads come alive - it goes up to 1k req/s and more. That sounds about right.
So unless i warm up the server with a few thousand test queries to create all threads - it gets overwhelmed for several minutes when the real load shows up, which causes a lot of warnings in the logs and massive retransmits from NASes (there are about 900 of them with lots of clients each), which is nasty. Having the server initialize Perl 256 times won't help. It will just push the delay *slightly* earlier. Well, it does really help, actually. After daemon startup, i'm doing "radclient -q -r 1 -t 10 -p 64 -s -f radius.256.test localhost auth secret" several times and then direct the load on the server. In this case it works fine, as the threads are already there to process the requests.
i.e. the server will either block and do nothing for a long time while it's initializing 256 Perl threads, or it will slowly process packets while it's initializing the Perl threads.
Either choice isn't perfect. And there's no real way around it. If Perl is slow to initialize... then it's slow to initialize. There's no magic you can do to make it faster. I don't want magic, i want Perl threads to initialize automatically after radiusd startup, not after the queries come in.
So the question is - this behavior is expected? I can, of course, warm up server after each restart but it seems irrational for me. Then you don't understand how computers work.
Hmm.. i can object, but i won't :)
My guess here is that the problem isn't starting up 256 Perl threads, the problem is that your Perl code is tens of thousands of lines long. And compiling *that* is taking forever.
So the solution is to not use complex Perl scripts.
My script is only 470 lines long, but it uses DBI module (and some minor others). Maybe it's quite complex and causing the slowdown.
Alan DeKok.
On 1 Apr 2016, at 08:20, Igor Novgorodov <igor@novg.net> wrote:
On 01.04.2016 17:00, Alan DeKok wrote:
On Apr 1, 2016, at 9:53 AM, Igor Novgorodov <igor@novg.net> wrote:
I've got latest 3.0.11 FreeRADIUS and Perl authorization module under rlm_perl. The server is relatively highly loaded (around 1000 access-requests per sec).
And although i have "start_servers = 256" and "min_spare_servers = 256" in the thread pool configuration, FreeRADIUS does not initialize those threads until the requests start to hit the daemon. FreeRADIUS starts all 256 threads. The "spare" threads are created as needed.
After some requests in parallel it spawns all required 256 threads and then this number stays constant.
The problem is that the thread creation in rlm_perl seems to be quite expensive timewise (or i may be doing something wrong?). Thread creation in Perl is very different than thread creation in the server core. The server starts 256 threads. BUT the Perl module still has to initialize any thread-specific context. That doesn't happen until the module is called. Ok, so there's no way to make it to initialize Perl's thread stuff when the server core threads are spawned?
Not currently. There's no hook for modules to do per-thread initialisation. For the majority of modules that's not an issue. It wouldn't be terribly hard to add something I guess... -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Okay, thank you very much for the info. I'll take a look on the rlm_perl code and maybe come up with a patch... In the meantime it seems that i have to add some logic to the init script that will: 1. Block RADIUS port in iptables to not overwhelm the daemon 2. Start FreeRADIUS 3. Warm the server up with radclient 4. Unblock port and let the main traffic flow in On 01.04.2016 17:28, Arran Cudbard-Bell wrote:
On 1 Apr 2016, at 08:20, Igor Novgorodov <igor@novg.net> wrote:
On 01.04.2016 17:00, Alan DeKok wrote:
On Apr 1, 2016, at 9:53 AM, Igor Novgorodov <igor@novg.net> wrote:
I've got latest 3.0.11 FreeRADIUS and Perl authorization module under rlm_perl. The server is relatively highly loaded (around 1000 access-requests per sec).
And although i have "start_servers = 256" and "min_spare_servers = 256" in the thread pool configuration, FreeRADIUS does not initialize those threads until the requests start to hit the daemon. FreeRADIUS starts all 256 threads. The "spare" threads are created as needed.
After some requests in parallel it spawns all required 256 threads and then this number stays constant.
The problem is that the thread creation in rlm_perl seems to be quite expensive timewise (or i may be doing something wrong?). Thread creation in Perl is very different than thread creation in the server core. The server starts 256 threads. BUT the Perl module still has to initialize any thread-specific context. That doesn't happen until the module is called. Ok, so there's no way to make it to initialize Perl's thread stuff when the server core threads are spawned? Not currently. There's no hook for modules to do per-thread initialisation. For the majority of modules that's not an issue.
It wouldn't be terribly hard to add something I guess...
-Arran
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Apr 1, 2016, at 10:20 AM, Igor Novgorodov <igor@novg.net> wrote:
Ok, so there's no way to make it to initialize Perl's thread stuff when the server core threads are spawned?
No. Because the Perl modules are buried in a virtual server. And because we have separate logical modules internally, the threads don't know about modules.
My script is only 470 lines long, but it uses DBI module (and some minor others). Maybe it's quite complex and causing the slowdown.
The DBI module is huge. If your Perl script is 470 lines, you can probably do all of that work in unlang. Alan DeKok.
On 01.04.2016 17:41, Alan DeKok wrote:
On Apr 1, 2016, at 10:20 AM, Igor Novgorodov <igor@novg.net> wrote:
Ok, so there's no way to make it to initialize Perl's thread stuff when the server core threads are spawned? No. Because the Perl modules are buried in a virtual server. And because we have separate logical modules internally, the threads don't know about modules. Got it.
My script is only 470 lines long, but it uses DBI module (and some minor others). Maybe it's quite complex and causing the slowdown. The DBI module is huge.
If your Perl script is 470 lines, you can probably do all of that work in unlang. Actually, i'm trying to migrate from unlang to Perl. Because of unlang's poor syntax (such as returning only one value from {%sql .. }) forces me to do more SQL queries and use some weird logic in them. So i'll better seek some workarounds with perl.
By the way, rlm_python is as slow in creating threads as rlm_perl? Maybe i should try it.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Apr 1, 2016, at 10:55 AM, Igor Novgorodov <igor@novg.net> wrote:
Because of unlang's poor syntax (such as returning only one value from {%sql .. }) forces me to do more SQL queries and use some weird logic in them.
Use v3.1.x from git. It has a "map" function which allows for multiple return values from SQL.
By the way, rlm_python is as slow in creating threads as rlm_perl? Maybe i should try it.
Python is probably worse. Alan DeKok.
On 01/04/16 16:09, Alan DeKok wrote:
On Apr 1, 2016, at 10:55 AM, Igor Novgorodov <igor@novg.net> wrote:
Because of unlang's poor syntax (such as returning only one value from {%sql .. }) forces me to do more SQL queries and use some weird logic in them.
Use v3.1.x from git. It has a "map" function which allows for multiple return values from SQL.
By the way, rlm_python is as slow in creating threads as rlm_perl? Maybe i should try it.
Python is probably worse.
Yeah, I love Python to bits, but it's a terrible fit for embedding in a threaded server, due to the GIL :o(
My script is only 470 lines long, but it uses DBI module (and some minor others). Maybe it's quite complex and causing the slowdown. The DBI module is huge.
If your Perl script is 470 lines, you can probably do all of that work in unlang. Actually, i'm trying to migrate from unlang to Perl. Because of unlang's poor syntax (such as returning only one value from {%sql .. })
map sql "SELECT ALL, THE, COLUMNS FROM STFU WHERE 1" { Reply-Message += 'ALL', Reply-Message += 'THE', Reply-Message += 'COLUMNS' } -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 1 Apr 2016, at 09:33, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
My script is only 470 lines long, but it uses DBI module (and some minor others). Maybe it's quite complex and causing the slowdown. The DBI module is huge.
If your Perl script is 470 lines, you can probably do all of that work in unlang. Actually, i'm trying to migrate from unlang to Perl. Because of unlang's poor syntax (such as returning only one value from {%sql .. })
map sql "SELECT ALL, THE, COLUMNS FROM STFU WHERE 1" { Reply-Message += 'ALL', Reply-Message += 'THE', Reply-Message += 'COLUMNS' }
-Arran
I have almost a complete rlm_lua implementation, there just doesn't seem to be a demand for it. Lua/LuaJIT was designed to be embedded, they are insanely fast (especially so with LuaJIT), lock free, and fits well with our current and future processing models. The marshalling/unmarshalling code in rlm_perl and rlm_python is complete garbage, the stuff I wrote for rlm_lua does everything on the fly as attributes are read from and written to. I expect marshalling rlm_python could be improved, but I hold out little hope for the steaming pile of filth that is Perl. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 1 Apr 2016, at 09:38, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 1 Apr 2016, at 09:33, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
My script is only 470 lines long, but it uses DBI module (and some minor others). Maybe it's quite complex and causing the slowdown. The DBI module is huge.
If your Perl script is 470 lines, you can probably do all of that work in unlang. Actually, i'm trying to migrate from unlang to Perl. Because of unlang's poor syntax (such as returning only one value from {%sql .. })
map sql "SELECT ALL, THE, COLUMNS FROM STFU WHERE 1" { Reply-Message += 'ALL', Reply-Message += 'THE', Reply-Message += 'COLUMNS' }
-Arran
I have almost a complete rlm_lua implementation, there just doesn't seem to be a demand for it.
Lua/LuaJIT was designed to be embedded, they are insanely fast (especially so with LuaJIT), lock free, and fits well with our current and future processing models.
The marshalling/unmarshalling code in rlm_perl and rlm_python is complete garbage, the stuff I wrote for rlm_lua does everything on the fly as attributes are read from and written to.
I expect marshalling rlm_python could be improved, but I hold out little hope for the steaming pile of filth that is Perl.
You know what, this has gone on for too long shinyhead:freeradius-server-fork arr2036$ rm -rf src/modules/rlm_perl/ shinyhead:freeradius-server-fork arr2036$ git commit -a -m "DIE PERL DIE" You need a passphrase to unlock the secret key for user: "Arran Cudbard-Bell <a.cudbardb@freeradius.org>" 4096-bit RSA key, ID 9FB6D7CA, created 2012-09-11 (main key ID 30A8CAA2) [upstream-v3.1.x 90f5fdb] DIE PERL DIE 6 files changed, 6056 deletions(-) delete mode 100644 src/modules/rlm_perl/.gitignore delete mode 100644 src/modules/rlm_perl/all.mk.in delete mode 100644 src/modules/rlm_perl/config.h.in delete mode 100755 src/modules/rlm_perl/configure delete mode 100644 src/modules/rlm_perl/configure.ac delete mode 100644 src/modules/rlm_perl/rlm_perl.c shinyhead:freeradius-server-fork arr2036$ git push Counting objects: 3328, done. Delta compression using up to 8 threads. Compressing objects: 100% (2739/2739), done. Writing objects: 100% (3328/3328), 524.30 KiB | 0 bytes/s, done. Total 3328 (delta 2701), reused 768 (delta 586) To ssh://git@github.com/FreeRADIUS/freeradius-server.git + 267e87a...1e00c5c v3.1.x -> v3.1.x Problem solved. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
But... but... we need that filth :'(
I expect marshalling rlm_python could be improved, but I hold out little hope for the steaming pile of filth that is Perl.
You know what, this has gone on for too long
shinyhead:freeradius-server-fork arr2036$ rm -rf src/modules/rlm_perl/ shinyhead:freeradius-server-fork arr2036$ git commit -a -m "DIE PERL DIE" You need a passphrase to unlock the secret key for user: "Arran Cudbard-Bell <a.cudbardb@freeradius.org>" 4096-bit RSA key, ID 9FB6D7CA, created 2012-09-11 (main key ID 30A8CAA2)
[upstream-v3.1.x 90f5fdb] DIE PERL DIE 6 files changed, 6056 deletions(-) delete mode 100644 src/modules/rlm_perl/.gitignore delete mode 100644 src/modules/rlm_perl/all.mk.in delete mode 100644 src/modules/rlm_perl/config.h.in delete mode 100755 src/modules/rlm_perl/configure delete mode 100644 src/modules/rlm_perl/configure.ac delete mode 100644 src/modules/rlm_perl/rlm_perl.c
shinyhead:freeradius-server-fork arr2036$ git push Counting objects: 3328, done. Delta compression using up to 8 threads. Compressing objects: 100% (2739/2739), done. Writing objects: 100% (3328/3328), 524.30 KiB | 0 bytes/s, done. Total 3328 (delta 2701), reused 768 (delta 586) To ssh://git@github.com/FreeRADIUS/freeradius-server.git + 267e87a...1e00c5c v3.1.x -> v3.1.x
Problem solved.
-Arran
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.
On Fri, Apr 01, 2016 at 12:05:36PM -0400, Alan DeKok wrote:
On Apr 1, 2016, at 12:02 PM, Chaigneau, Nicolas <nicolas.chaigneau@capgemini.com> wrote:
But... but... we need that filth :'(
In related news, I've realized my mistake of the last 17 years. I'll be moving over to work with Diameter 100% of the time.
This is a good idea. RADIUS is half the size it needs to be for today's networks. I would also like to propose that unlang, given its flexibility now, is renamed "lang". See pull request #0104. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On 1 Apr 2016, at 10:11, Matthew Newton <mcn4@leicester.ac.uk> wrote:
On Fri, Apr 01, 2016 at 12:05:36PM -0400, Alan DeKok wrote:
On Apr 1, 2016, at 12:02 PM, Chaigneau, Nicolas <nicolas.chaigneau@capgemini.com> wrote:
But... but... we need that filth :'(
In related news, I've realized my mistake of the last 17 years. I'll be moving over to work with Diameter 100% of the time.
This is a good idea. RADIUS is half the size it needs to be for today's networks.
I would also like to propose that unlang, given its flexibility now, is renamed "lang".
See pull request #0104.
Given our strict adherence to published internetworking standards, I suggest that we transition lang to use YANG for markup. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Apr 2, 2016 5:18 AM, "Arran Cudbard-Bell" <a.cudbardb@freeradius.org> wrote:
On 1 Apr 2016, at 10:11, Matthew Newton <mcn4@leicester.ac.uk> wrote:
On Fri, Apr 01, 2016 at 12:05:36PM -0400, Alan DeKok wrote:
On Apr 1, 2016, at 12:02 PM, Chaigneau, Nicolas <
nicolas.chaigneau@capgemini.com> wrote:
But... but... we need that filth :'(
In related news, I've realized my mistake of the last 17 years. I'll be moving over to work with Diameter 100% of the time.
This is a good idea. RADIUS is half the size it needs to be for today's networks.
I would also like to propose that unlang, given its flexibility now, is renamed "lang".
See pull request #0104.
Given our strict adherence to published internetworking standards, I suggest that we transition lang to use YANG for markup.
And rewrite the all the code in GoLang rather than C like all the cool kids do these days.
-Arran
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
- List info/subscribe/unsubscribe? See
On 1 Apr 2016, at 19:19, Peter Lambrechtsen <peter@crypt.nz> wrote:
On Apr 2, 2016 5:18 AM, "Arran Cudbard-Bell" <a.cudbardb@freeradius.org> wrote:
On 1 Apr 2016, at 10:11, Matthew Newton <mcn4@leicester.ac.uk> wrote:
On Fri, Apr 01, 2016 at 12:05:36PM -0400, Alan DeKok wrote:
On Apr 1, 2016, at 12:02 PM, Chaigneau, Nicolas <
nicolas.chaigneau@capgemini.com> wrote:
But... but... we need that filth :'(
In related news, I've realized my mistake of the last 17 years. I'll be moving over to work with Diameter 100% of the time.
This is a good idea. RADIUS is half the size it needs to be for today's networks.
I would also like to propose that unlang, given its flexibility now, is renamed "lang".
See pull request #0104.
Given our strict adherence to published internetworking standards, I suggest that we transition lang to use YANG for markup.
And rewrite the all the code in GoLang rather than C like all the cool kids do these days.
Pfft GoLang is so 2015, Rust is where it's at. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Today i rewrote my rlm_perl stuff in Go+fasthttp and attached FreeRADIUS to it with rlm_rest - the combination works wonderful. I already started to love Go for it's scalability. Is Rust even better? ;) On 04.04.2016 19:40, Arran Cudbard-Bell wrote:
On 1 Apr 2016, at 19:19, Peter Lambrechtsen <peter@crypt.nz> wrote:
On Apr 2, 2016 5:18 AM, "Arran Cudbard-Bell" <a.cudbardb@freeradius.org> wrote:
On 1 Apr 2016, at 10:11, Matthew Newton <mcn4@leicester.ac.uk> wrote:
On Fri, Apr 01, 2016 at 12:05:36PM -0400, Alan DeKok wrote:
On Apr 1, 2016, at 12:02 PM, Chaigneau, Nicolas <
nicolas.chaigneau@capgemini.com> wrote:
But... but... we need that filth :'( In related news, I've realized my mistake of the last 17 years. I'll be moving over to work with Diameter 100% of the time. This is a good idea. RADIUS is half the size it needs to be for today's networks.
I would also like to propose that unlang, given its flexibility now, is renamed "lang".
See pull request #0104. Given our strict adherence to published internetworking standards, I suggest that we transition lang to use YANG for markup.
And rewrite the all the code in GoLang rather than C like all the cool kids do these days. Pfft GoLang is so 2015, Rust is where it's at.
-Arran
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Apr 1, 2016, at 11:38 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
I have almost a complete rlm_lua implementation, there just doesn't seem to be a demand for it.
I would recommend it over Perl or Python.
The marshalling/unmarshalling code in rlm_perl and rlm_python is complete garbage, the stuff I wrote for rlm_lua does everything on the fly as attributes are read from and written to.
Which is much better.
I expect marshalling rlm_python could be improved, but I hold out little hope for the steaming pile of filth that is Perl.
If rlm_lua is in 3.1, I would mark Python and Perl as deprecated. "Use at your own risk". The nice thing about Perl is CPAN. It has so many libraries that it's insanely useful. The sad thing about Perl is that compiling 100K of code from CPAN is slow. Alan DeKok.
On 01-04-16 16:00, Alan DeKok wrote:
My guess here is that the problem isn't starting up 256 Perl threads, the problem is that your Perl code is tens of thousands of lines long. And compiling *that* is taking forever.
There is another problem here: every freeradius thread tries to compile the perl-code separately and keeps a compiled version in memory. The more threads you have, the more memory is allocated just for the perl code. Those embedded languages are great for things that are not too complex. Otherwise, it might be worth a try to use rlm_rest and use a webserver that preloads the perl code. We had some good experiences with AnyEvent::HTTPD in Perl. -- Herwin Weststrate
On Apr 1, 2016, at 11:31 AM, Herwin Weststrate <herwin@quarantainenet.nl> wrote:
There is another problem here: every freeradius thread tries to compile the perl-code separately and keeps a compiled version in memory. The more threads you have, the more memory is allocated just for the perl code.
That's likely a limitation of Perl (? maybe ?) If Perl supported it, the module could just load the Perl code, compile it at module start, and then cache that for the threads to use. That would be a LOT faster. Alan DeKok.
participants (9)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
Chaigneau, Nicolas -
Herwin Weststrate -
Igor Novgorodov -
Matthew Newton -
Peter Lambrechtsen -
Phil Mayers