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 :) 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 :-) 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 :-) > >> > >>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 -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
