So to confirm, your new module is basically files module, but it does
NOT cache anything in directory, but re-read the files on disk for
every request, is that correct?
Roughly correct. No caching, and reads on disk for every request. We rely on
the block-buffer cache to make it go
- each user performing 7 authentications during EAP negotiation
ummm, why? with correctly configured server and 'protection' of the
authentication
type, you should only hit your authentication server just once inside the
EAP tunnel when the identity is set/known.
I'm not across the
I'd normally just put users into SQL.
Yes - this was our default approach. It made the most sense to us initially.
rlm_sql
- highly dynamic
- need non-trivial skills to config right for performance
- need extra h/w to scale for white-hot performance
rlm_files
- not so dynamic (regular
On Tue, Jan 24, 2012 at 9:53 AM, Claude Brown
claude.br...@vividwireless.com.au wrote:
Our design goal is:
- 250K users all needing to get on the network at the same time
- each user performing 7 authentications during EAP negotiation
- one hour duration to get everyone sorted
This is about
Hi,
- each user performing 7 authentications during EAP negotiation
ummm, why? with correctly configured server and 'protection' of the
authentication
type, you should only hit your authentication server just once inside the
EAP tunnel when the identity is set/known.
alan
-
List
Claude Brown wrote:
My original reply was confusingly brief. I've clarified below, and I've also
put the module we wrote into github in case it helps:
https://github.com/claudebrown/freeradius-server/compare/master...rlm_tagfiles
OK. It's... odd.
We avoided both fastfile and reloading
Claude Brown wrote:
We didn't try this.
That would fix it.
Our design goal is:
- 250K users all needing to get on the network at the same time
- each user performing 7 authentications during EAP negotiation
That should be fixed, too. There is NO NEED to do 7 SQL queries. You
can put
Alan,
My original reply was confusingly brief. I've clarified below, and I've also
put the module we wrote into github in case it helps:
https://github.com/claudebrown/freeradius-server/compare/master...rlm_tagfiles
(about 60 lines of C beyond usual module plumbing; 250 lines in total)
Alan
Bjorn,
Thanks.
You don't even need to be that careful. Just run a read-only mysql
slave instance locally on the radius server and all mysql-related
performance problems will vanish.
We didn't try this.
Our design goal is:
- 250K users all needing to get on the network at the same time
-
claude.brown wrote:
Our new module was designed to replace rlm_sql and meet these goals:
- Be roughly equivalent to rlm_files in terms of speed
- Utilise all the features of rlm_files - avoid re-inventing that wheel
- Allow high rate of user-by-user updates; i.e. avoid config re-write as per
Alan DeKok al...@deployingradius.com writes:
claude.brown wrote:
- Performance issues on our MySQL backend that we didn't have budget to
resolve
- Thread lock-up's inside MySQL library yet no MySQL server queries were
active
I've seen lots of people running MySQL with 300K+ users, and no
In the end we implemented our solution as a new C module rather than perl
called by rlm_perl. Thanks.
Our new module was designed to replace rlm_sql and meet these goals:
- Be roughly equivalent to rlm_files in terms of speed
- Utilise all the features of rlm_files - avoid re-inventing that
Hi,
First, the version I'm using:
# freeradius -v
freeradius: FreeRADIUS Version 2.1.8, for host x86_64-pc-linux-gnu, [...]
I'm trying to control the attribute-ordering when using rlm_perl. Thus far my
experience is that this is not possible. My theory is that this is due to the
hash-tables
Claude Brown wrote:
I'm trying to control the attribute-ordering when using rlm_perl. Thus far
my experience is that this is not
possible. My theory is that this is due to the hash-tables used as the
interface between the C and Perl worlds.
Quite possibly.
The ordering is important to for
14 matches
Mail list logo
