Maybe you're both right? But who really wants to win a "Who's the bigger nerd contest"? If I have a small set of users, I'm using the flat file. But if my user list grows....no doubt use SQL. The best thing for me is I don't have to write fancy text handlers to parse through the users file, I just use SQL statements.
So as far as speed, it's negligible either way. Separation of data....now that's where it's at.......... Steven You wrote: > Well, if that is such a big problem then you can do a memory disk and > store your db files in memory disk. That would then definetely work > better than freeradius itself. How much are the memory prices now anyhow. > About the operating system stuff, the load of exchanging few messages in > memory can not be so overwhelming compared to an inefficient search of a > few hundred thousands of users from a text database even when its in > memory already. > There so many programs running in background usually that I am sure that > many programs trigger the kernel context switching already even when > freeradius is searching from the users file. Now the point is if the > search is faster then it would be interrupted less since it would take > less time to finish. Thus using SQL would yet improve performance anyhow > since the searches would take a lot less time. > Look at some statistics > http://cs.nmu.edu/~benchmark/index.php?page=context > The context switching occurs in microseconds. Lets try to calculate how > many context switching operations can be done in a second? Needless to > remind that a microsecond is 10^-6 of a second. > Then think about how much difference would it take to search 100000 > entries from users file in memory or in sql database. In which sql > already optimize the data to be searched. Then find out how many context > switching can be done in that much time <IMG SRC="/images/emoticon14.gif"> > I am certainly uncertain about how much overhead it cause for freeradius > to call to mysql and back but it can not be so much. Plus if you have > 100000 users you do not want to reload the users file <IMG > SRC="/images/emoticon14.gif"> think about > reading 100000 users from the disk. Now is that more efficient? in every > stupid reload. Then calculate the people who change their passwords or > new customers coming and new accounts added. > You cant possible argue that using users file is faster. But perhaps the > difference is so little when you have few thousand users that you can > omit the difference. > Evren > Peter Nixon wrote: > > On Tue August 5 2003 05:34, Evren Yurtesen wrote: > > > >>Thats totally wrong, so you say same cpu works on both db lookups and > >>freeradius, now when freeradius is making a lookup inside users file > >>which is in ram, the same cpu doesnt work on db lookups in memory or > >>what? so thats out of question. > > > > > > I am sorry to tell you Evren, but you ARE wrong. Even if you forget for a > > moment the fact that a DB server has to fetch the data from the disk and > > FreeRadius does not, It is MUCH more efficient for FreeRadius to search it's > > own memory space than to ask another program to supply the data. > > > > Asking another program (A DB server or any other program) even if that > >program > > already has the data in memory is very slow comparitively as it forces a > > kernel context switch to load the other program onto the CPU, then another > > context switch to load FreeRadius onto the CPU. > > > > Put simply you are wrong. Please read up about CPU design and operating > >system > > context switches before argueing this any more. > > > > > >>but mysql is optimized for that kind of lookups, there is huge > >>difference. then again, you can increase the mysql memory cache that > >>mysql can cache the whole db inside the ram if it is small enough. > > > > > > It is not. There is not. You are wrong. Even if you have the entire DB inside > > > > ram (which would nullify your point of using a DB instead of a client file to > > > > save on RAM usage) the CPU still has to switch the running context from FR -> > > > > DB -> FR which flushes all CPU caches and is very slow. not to mention the > > fact that there is TCP (or UNIX) socket overhead to slow things down. Of > > course there is also Parsing and reparsing of SQL statements etc etc.. > > > > > >>Now about searching in ram is better than using a database backend. I > >>wonder why companies do not store their database data in text files and > >>load them to ram <IMG SRC="/images/emoticon14.gif"> > > > > > > They do. Of course they do. It is always faster to load data at run time than > > > > look it up later. using a DB is easier/better for maintenence. It is NOT > > faster. > > > > > >>now the problem is that also everytime you reload > >>radius it reloads the whole file since it cant know where the changed > >>data is. Thus uses far more cpu. > > > > > > this ONLY happens at startup. how can it possibly use more CPU than > >requesting > > from disk for every query???!!! > > > > > >>It is definetely not a good thing if > >>you want your users to change their passwords from web, then you need to > >>write to users file and reload radius if you do not use sql. > > > > > > Yes. As mentioned before. DB is good for easy maintenence, NOT speed. > > > > > >>If you use > >>sql you can create a user which can only change some parts of the > >>database and limit the access. It is even more secure when configured > >>properly. It is 100 times easier to write a php script which does that > >>than writing it in c or perl > > > > > > We were argueing about speed, not other issues. DBs are good, but you are > >VERY > > wrong about them being faster than a memory search of the clients file.. > > > > If case you were wondering I maintain the postgresql configs and driver for > > FreeRadius, and run a DB backend with many GB of data in it.. Trust me, I > > know what I am talking about more than you do <IMG SRC="/images/emoticon11.gif"> > > > > Peter > > > > > >>Graeme Hinchliffe wrote: > >> > >>>On Mon, 4 Aug 2003 18:01:07 +0200 > >>> > >>>"Andrea Coppini" <[EMAIL PROTECTED]> wrote: > >>> > >>>>>DB backends are good, and save alot of admin, but don't expect them to > >>>> > >>>>be > >>>> > >>>> > >>>>>faster than a memory scan <IMG SRC="/images/emoticon11.gif"> > >>>> > >>>>I haven't done any tests, but I would presume an SQL backend would be > >>>>more 'robust' than freeradius. > >>>> > >>>>The way I see it, having 1 request a minute is definitely faster with a > >>>>users file in memory, but when the load hits and you have 10,000 hits > >>>>per minute, freeradius would grind to a halt having to look up the > >>>>credentials and handling all NAS comms simultaneously, while freeradius > >>>>+ sql would just continue doing their respective jobs as normal. > >>> > >>>But as the same CPU would be working on the DB lookups AND the freeRADIUS > >>>code as well, it would slow down by a much larger factor. You would now > >>>have 2 processes sharing the memory and CPU resources and bus of the > >>>system etc.. > >>> > >>>Fact is Disk access is horribly slow compared to memory. > >>> > >>>Look at the spec of a fairly old (now) PC.. 100MHz FSB.. so thats around > >>>100,000,000*4 bytes per SECOND which is a tiny bit faster than a HDD > >>>don't you think. > >>> > >>>Just look at the clock speed of your PC.. even if the data wasn't indexed > >>>in memory and was searched in a linear manner it would still be extremely > >>>quick in comparison to a db. > >>> > >>>Graeme > >> > >>- > >>List info/subscribe/unsubscribe? See > >>http://www.freeradius.org/list/users.html > > > > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html --
