RE: Advantages of Using SQL ?
It is a good analogy, obviously if you had millions of girlfriends it would take more memory :) Memory in both cases would still be faster, anything loaded in memory will always be faster, anything accessing a harddrive will almost always be the bottleneck compard to loading from memory. Jeremy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Peter Nixon Sent: Tuesday, August 05, 2003 2:34 AM To: [EMAIL PROTECTED] Subject: Re: Advantages of Using SQL ? On Tue August 5 2003 08:32, SIMICRO ML wrote: > Peter Nixon wrote: > > On Tue August 5 2003 06:37, Evren Yurtesen wrote: > > > > Its like saying that example B is faster than example A in the following > > scenario: > > > > A) You need to call your girlfriend. You know her number, so you dial it > > and talk to her. > > > > B) You need to call your girlfriend, You don't know her number so you > > call your secretary and ask her to look it up in the phone book. Your > > secretary looks up the number, calls you back and give it to you, then > > you call your girlfriend. > > > > Which do you thing is faster?? Bzzzt. WRONG ANSWER. Just because the > > phone book has a great, wonderfully efficient index, and your secretary > > is very good at using it, doesn't mean that it's faster than having the > > number in your own head > > ... and what if you had _millions_ of girlfriends :-D Yes. Like all analogies it not perfect, but it does illistrate the point we were talking about. -- 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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Advantages of Using SQL ?
On Tue, 5 Aug 2003 10:51:45 -0400 Robert LaGrasse <[EMAIL PROTECTED]> wrote: > If I could remember the names and numbers of millions of girlfriends > simultaneously, I could still call any of them faster myself. Having a > secretary to keep track of my dates and remind me when special occasions > come up is also useful. Either way, I'm a pretty happy guy... If you had millions of girlfriends I doubt you would be happy, more a very poor pale looking guy that twitches uncontrollably and gibbers to himself :) Just the one is tough enough.. a million of them.. thats just scarey! :) -- - Graeme Hinchliffe (BSc) Core Team Member Zen Internet (http://www.zen.co.uk) ICQ 3842605 (link) Direct: 01706 900 212 Sales : 0870 6000 971 Fax : 0870 6000 972 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Advantages of Using SQL ?
But the argument was never about effiency, it was about speed. SQL makes a lot more sense if you have a lot of users. The maintence would be easier as well. Jeremy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Evren Yurtesen Sent: Tuesday, August 05, 2003 9:02 PM To: [EMAIL PROTECTED] Subject: Re: Advantages of Using SQL ? maybe thats the problem, you are not designed to remember millions of girlfriends names/numbers etc. thats why you are inefficient by design in this area particular area of operation. so you hire a secretary which will improve your efficiency :) Evren Robert LaGrasse wrote: > If I could remember the names and numbers of millions of girlfriends > simultaneously, I could still call any of them faster myself. Having a > secretary to keep track of my dates and remind me when special occasions > come up is also useful. Either way, I'm a pretty happy guy... > > ;) > > > -Original Message- > From: SIMICRO ML [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 05, 2003 1:32 AM > To: [EMAIL PROTECTED] > Subject: Re: Advantages of Using SQL ? > > > Peter Nixon wrote: > >>On Tue August 5 2003 06:37, Evren Yurtesen wrote: > > >>Its like saying that example B is faster than example A in the following >>scenario: >> >>A) You need to call your girlfriend. You know her number, so you dial it > > and > >>talk to her. >> >>B) You need to call your girlfriend, You don't know her number so you call > > >>your secretary and ask her to look it up in the phone book. Your secretary > > >>looks up the number, calls you back and give it to you, then you call your > > >>girlfriend. >> >>Which do you thing is faster?? Bzzzt. WRONG ANSWER. Just because the phone > > >>book has a great, wonderfully efficient index, and your secretary is very >>good at using it, doesn't mean that it's faster than having the number in >>your own head > > > ... and what if you had _millions_ of girlfriends :-D > > @+ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Advantages of Using SQL ?
If I could remember the names and numbers of millions of girlfriends simultaneously, I could still call any of them faster myself. Having a secretary to keep track of my dates and remind me when special occasions come up is also useful. Either way, I'm a pretty happy guy... ;) -Original Message- From: SIMICRO ML [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 05, 2003 1:32 AM To: [EMAIL PROTECTED] Subject: Re: Advantages of Using SQL ? Peter Nixon wrote: > On Tue August 5 2003 06:37, Evren Yurtesen wrote: > Its like saying that example B is faster than example A in the following > scenario: > > A) You need to call your girlfriend. You know her number, so you dial it and > talk to her. > > B) You need to call your girlfriend, You don't know her number so you call > your secretary and ask her to look it up in the phone book. Your secretary > looks up the number, calls you back and give it to you, then you call your > girlfriend. > > Which do you thing is faster?? Bzzzt. WRONG ANSWER. Just because the phone > book has a great, wonderfully efficient index, and your secretary is very > good at using it, doesn't mean that it's faster than having the number in > your own head ... and what if you had _millions_ of girlfriends :-D @+ -- DouRiX [PLEBISCITE, n. A popular vote to ascertain the will of the sovereign. -- Ambrose Bierce] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Advantages of Using SQL ?
On Tue, 05 Aug 2003 18:02:24 -0700 Evren Yurtesen <[EMAIL PROTECTED]> wrote: > maybe thats the problem, you are not designed to remember millions of > girlfriends names/numbers etc. thats why you are inefficient by design > in this area particular area of operation. > > so you hire a secretary which will improve your efficiency :) But then you could potentially end up with the secretary becoming a girlfriend, which could lead to a recursive search, especially if you then hired a replacement secretary. And we all know recursive searches can be resource hungry :) NB: to understand recursion, we must first understand recursion -- - Graeme Hinchliffe (BSc) Core Team Member Zen Internet (http://www.zen.co.uk) ICQ 3842605 (link) Direct: 01706 900 212 Sales : 0870 6000 971 Fax : 0870 6000 972 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Advantages of Using SQL ?
maybe thats the problem, you are not designed to remember millions of girlfriends names/numbers etc. thats why you are inefficient by design in this area particular area of operation. so you hire a secretary which will improve your efficiency :) Evren Robert LaGrasse wrote: If I could remember the names and numbers of millions of girlfriends simultaneously, I could still call any of them faster myself. Having a secretary to keep track of my dates and remind me when special occasions come up is also useful. Either way, I'm a pretty happy guy... ;) -Original Message- From: SIMICRO ML [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 05, 2003 1:32 AM To: [EMAIL PROTECTED] Subject: Re: Advantages of Using SQL ? Peter Nixon wrote: On Tue August 5 2003 06:37, Evren Yurtesen wrote: Its like saying that example B is faster than example A in the following scenario: A) You need to call your girlfriend. You know her number, so you dial it and talk to her. B) You need to call your girlfriend, You don't know her number so you call your secretary and ask her to look it up in the phone book. Your secretary looks up the number, calls you back and give it to you, then you call your girlfriend. Which do you thing is faster?? Bzzzt. WRONG ANSWER. Just because the phone book has a great, wonderfully efficient index, and your secretary is very good at using it, doesn't mean that it's faster than having the number in your own head ... and what if you had _millions_ of girlfriends :-D @+ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Advantages of Using SQL ?
I think if you had millions of girlfriends you would be broke :) *lol* and your memory would wear off because of too many write attempts from millions of girlfriends. :))) Jeremy Davis wrote: It is a good analogy, obviously if you had millions of girlfriends it would take more memory :) Memory in both cases would still be faster, anything loaded in memory will always be faster, anything accessing a harddrive will almost always be the bottleneck compard to loading from memory. Jeremy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Peter Nixon Sent: Tuesday, August 05, 2003 2:34 AM To: [EMAIL PROTECTED] Subject: Re: Advantages of Using SQL ? On Tue August 5 2003 08:32, SIMICRO ML wrote: Peter Nixon wrote: On Tue August 5 2003 06:37, Evren Yurtesen wrote: Its like saying that example B is faster than example A in the following scenario: A) You need to call your girlfriend. You know her number, so you dial it and talk to her. B) You need to call your girlfriend, You don't know her number so you call your secretary and ask her to look it up in the phone book. Your secretary looks up the number, calls you back and give it to you, then you call your girlfriend. Which do you thing is faster?? Bzzzt. WRONG ANSWER. Just because the phone book has a great, wonderfully efficient index, and your secretary is very good at using it, doesn't mean that it's faster than having the number in your own head ... and what if you had _millions_ of girlfriends :-D Yes. Like all analogies it not perfect, but it does illistrate the point we were talking about. -- 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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Advantages of Using SQL ?
> > 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. > > What is so inefficient about the search algorithm used by FreeRadius. (I have > not looked currently) If is IS slow, then once again, we can simply use the > "efficient" algorithm from MySQL instead of the one currently in use. Perhaps FreeRADIUS generates a random number and then checks the corresponding entry, if it's not right it does a do nothing loop for a bit and then generates another random number.. repeat until it finds the record. :) -- - Graeme Hinchliffe (BSc) Core Team Member Zen Internet (http://www.zen.co.uk) ICQ 3842605 (link) Direct: 01706 900 212 Sales : 0870 6000 971 Fax : 0870 6000 972 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Advantages of Using SQL ?
On Tue August 5 2003 08:32, SIMICRO ML wrote: > Peter Nixon wrote: > > On Tue August 5 2003 06:37, Evren Yurtesen wrote: > > > > Its like saying that example B is faster than example A in the following > > scenario: > > > > A) You need to call your girlfriend. You know her number, so you dial it > > and talk to her. > > > > B) You need to call your girlfriend, You don't know her number so you > > call your secretary and ask her to look it up in the phone book. Your > > secretary looks up the number, calls you back and give it to you, then > > you call your girlfriend. > > > > Which do you thing is faster?? Bzzzt. WRONG ANSWER. Just because the > > phone book has a great, wonderfully efficient index, and your secretary > > is very good at using it, doesn't mean that it's faster than having the > > number in your own head > > ... and what if you had _millions_ of girlfriends :-D Yes. Like all analogies it not perfect, but it does illistrate the point we were talking about. -- 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
Re: Advantages of Using SQL ?
Peter Nixon wrote: On Tue August 5 2003 06:37, Evren Yurtesen wrote: Its like saying that example B is faster than example A in the following scenario: A) You need to call your girlfriend. You know her number, so you dial it and talk to her. B) You need to call your girlfriend, You don't know her number so you call your secretary and ask her to look it up in the phone book. Your secretary looks up the number, calls you back and give it to you, then you call your girlfriend. Which do you thing is faster?? Bzzzt. WRONG ANSWER. Just because the phone book has a great, wonderfully efficient index, and your secretary is very good at using it, doesn't mean that it's faster than having the number in your own head ... and what if you had _millions_ of girlfriends :-D @+ -- DouRiX [PLEBISCITE, n. A popular vote to ascertain the will of the sovereign. -- Ambrose Bierce] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Advantages of Using SQL ?
I hit the wrong button - please see the remainder of message below. On Mon, 04 Aug 2003 15:55:46 -0500 "Tim McCracken" <[EMAIL PROTECTED]> wrote: My numbers (atleast) were a joke. The reality of it is (IMHO) that benchmarks are only useful to marketing departments because they are rarely done in an equitable manner. There are way too many differences to benchmark accross hardware platforms, and rarely does anyone tune OS parameters to make benchmarks meaningful on different OSs using the same hardware. I use Win2K and Solaris and XP extensively. IMHO, each has an efficient kernel. All will run the following program very fast: while(1) ; It is the bloated upper layers that everyone has a problem with - the registry, basing everything on COM, legacy DOS file support The kernel was designed by the same guy that designed VAX VMS - arugably the best OS ever built. He just had no control over what got piled on top of it. Tim On Mon, 04 Aug 2003 23:37:42 -0700 Evren Yurtesen <[EMAIL PROTECTED]> wrote: How do you test this? or joke? :) I would like to keep record of my server performances relative to each other too, it sounds like a cool idea Evren Tim McCracken wrote: My testing confirms Alan's numbers, however he neglected to mention: Solaris: 2.5 VMS on Alpha: 8.0 :) On Mon, 04 Aug 2003 16:07:58 -0400 "Alan DeKok" <[EMAIL PROTECTED]> wrote: Evren Yurtesen <[EMAIL PROTECTED]> wrote: Everybody argue about something and usually its so difficult to come to a conclusion. Microsoft says windows is good, linux people say linux is better, I say FreeBSD is best :) NetBSD... Microsoft always says the newer version of windows works faster and more efficiently etc. But yet they require faster cpu's and more memory in their system requirements :) When we leave the memory out, I wonder why a more efficient system require faster cpu :) there is a problem in this equation :) At work, we run CPU and memory intensive applications. On the same hardward, the relative speed of our apps on the various OS's, relative to NetBSD, are: NetBSD: 1.0 Linux : 0.6 XP: 0.2 NT4 : >0.1 So I agree, XP is twice as good as NT4. :) Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Advantages of Using SQL ?
My numbers (atleast) were a joke. The reality of it is (IMHO) that benchmarks are only useful to marketing departments because they are rarely done in an equitable manner. There are way too many differences to benchmark accross hardware platforms, and rarely does anyone tune OS parameters to make benchmarks meaningful on different OSs using the same hardware. I use Win2K and Solaris and XP extensively. IMHO, each has an efficient kernel. All will run the following program very fast: while(1) Tim On Mon, 04 Aug 2003 23:37:42 -0700 Evren Yurtesen <[EMAIL PROTECTED]> wrote: How do you test this? or joke? :) I would like to keep record of my server performances relative to each other too, it sounds like a cool idea Evren Tim McCracken wrote: My testing confirms Alan's numbers, however he neglected to mention: Solaris: 2.5 VMS on Alpha: 8.0 :) On Mon, 04 Aug 2003 16:07:58 -0400 "Alan DeKok" <[EMAIL PROTECTED]> wrote: Evren Yurtesen <[EMAIL PROTECTED]> wrote: Everybody argue about something and usually its so difficult to come to a conclusion. Microsoft says windows is good, linux people say linux is better, I say FreeBSD is best :) NetBSD... Microsoft always says the newer version of windows works faster and more efficiently etc. But yet they require faster cpu's and more memory in their system requirements :) When we leave the memory out, I wonder why a more efficient system require faster cpu :) there is a problem in this equation :) At work, we run CPU and memory intensive applications. On the same hardward, the relative speed of our apps on the various OS's, relative to NetBSD, are: NetBSD: 1.0 Linux : 0.6 XP: 0.2 NT4 : >0.1 So I agree, XP is twice as good as NT4. :) Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Advantages of Using SQL ?
My numbers (atleast) were a joke. The reality of it is (IMHO) that benchmarks are only useful to marketing departments because they are rarely done in an equitable manner. There are way too many differences to benchmark accross hardware platforms, and rarely does anyone tune OS parameters to make benchmarks meaningful on different OSs using the same hardware. I use Win2K and Solaris and XP extensively. IMHO, each has an efficient kernel. All will run the following program very fast: while(1) Tim On Mon, 04 Aug 2003 23:37:42 -0700 Evren Yurtesen <[EMAIL PROTECTED]> wrote: How do you test this? or joke? :) I would like to keep record of my server performances relative to each other too, it sounds like a cool idea Evren Tim McCracken wrote: My testing confirms Alan's numbers, however he neglected to mention: Solaris: 2.5 VMS on Alpha: 8.0 :) On Mon, 04 Aug 2003 16:07:58 -0400 "Alan DeKok" <[EMAIL PROTECTED]> wrote: Evren Yurtesen <[EMAIL PROTECTED]> wrote: Everybody argue about something and usually its so difficult to come to a conclusion. Microsoft says windows is good, linux people say linux is better, I say FreeBSD is best :) NetBSD... Microsoft always says the newer version of windows works faster and more efficiently etc. But yet they require faster cpu's and more memory in their system requirements :) When we leave the memory out, I wonder why a more efficient system require faster cpu :) there is a problem in this equation :) At work, we run CPU and memory intensive applications. On the same hardward, the relative speed of our apps on the various OS's, relative to NetBSD, are: NetBSD: 1.0 Linux : 0.6 XP: 0.2 NT4 : >0.1 So I agree, XP is twice as good as NT4. :) Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Advantages of Using SQL ?
How do you test this? or joke? :) I would like to keep record of my server performances relative to each other too, it sounds like a cool idea Evren Tim McCracken wrote: My testing confirms Alan's numbers, however he neglected to mention: Solaris: 2.5 VMS on Alpha: 8.0 :) On Mon, 04 Aug 2003 16:07:58 -0400 "Alan DeKok" <[EMAIL PROTECTED]> wrote: Evren Yurtesen <[EMAIL PROTECTED]> wrote: Everybody argue about something and usually its so difficult to come to a conclusion. Microsoft says windows is good, linux people say linux is better, I say FreeBSD is best :) NetBSD... Microsoft always says the newer version of windows works faster and more efficiently etc. But yet they require faster cpu's and more memory in their system requirements :) When we leave the memory out, I wonder why a more efficient system require faster cpu :) there is a problem in this equation :) At work, we run CPU and memory intensive applications. On the same hardward, the relative speed of our apps on the various OS's, relative to NetBSD, are: NetBSD: 1.0 Linux : 0.6 XP: 0.2 NT4 : >0.1 So I agree, XP is twice as good as NT4. :) Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Advantages of Using SQL ?
My testing confirms Alan's numbers, however he neglected to mention: Solaris: 2.5 VMS on Alpha: 8.0 :) On Mon, 04 Aug 2003 16:07:58 -0400 "Alan DeKok" <[EMAIL PROTECTED]> wrote: Evren Yurtesen <[EMAIL PROTECTED]> wrote: Everybody argue about something and usually its so difficult to come to a conclusion. Microsoft says windows is good, linux people say linux is better, I say FreeBSD is best :) NetBSD... Microsoft always says the newer version of windows works faster and more efficiently etc. But yet they require faster cpu's and more memory in their system requirements :) When we leave the memory out, I wonder why a more efficient system require faster cpu :) there is a problem in this equation :) At work, we run CPU and memory intensive applications. On the same hardward, the relative speed of our apps on the various OS's, relative to NetBSD, are: NetBSD: 1.0 Linux : 0.6 XP: 0.2 NT4 : >0.1 So I agree, XP is twice as good as NT4. :) Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Advantages of Using SQL ?
Evren Yurtesen <[EMAIL PROTECTED]> wrote: > Everybody argue about something and usually its so difficult to come to > a conclusion. Microsoft says windows is good, linux people say linux is > better, I say FreeBSD is best :) NetBSD... > Microsoft always says the newer version of windows works faster and more > efficiently etc. But yet they require faster cpu's and more memory in > their system requirements :) When we leave the memory out, I wonder why > a more efficient system require faster cpu :) there is a problem in this > equation :) At work, we run CPU and memory intensive applications. On the same hardward, the relative speed of our apps on the various OS's, relative to NetBSD, are: NetBSD: 1.0 Linux : 0.6 XP: 0.2 NT4 : >0.1 So I agree, XP is twice as good as NT4. :) Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Advantages of Using SQL ?
Sometimes this comes down to what you need it to do. I need a centralized user database platform wide so LDAP was the obvious choice so I ran that with detail accounting for a while but then I needed to do some bit counting and I also needed to calculate usage for the users. When it comes to this it is MUCH faster and easier to work with the database. Now I just ask the database for the the usage instead of trying to parse a huge text log. schu Evren Yurtesen wrote: Ok lets make peace :) Everybody argue about something and usually its so difficult to come to a conclusion. Microsoft says windows is good, linux people say linux is better, I say FreeBSD is best :) Anyhow the hardware is so fast and cheap nowadays that we dont need to be so efficient :) It is better to install things the most productive way. Usually it is enough... By the way I would like to finish this with something which I think funny: I just remembered something when I thought about efficient. Microsoft always says the newer version of windows works faster and more efficiently etc. But yet they require faster cpu's and more memory in their system requirements :) When we leave the memory out, I wonder why a more efficient system require faster cpu :) there is a problem in this equation :) Evren - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Advantages of Using SQL ?
I'm still confused why you're arguing over this...It's implemented both ways for a reason I assume. So if the flat file is so great, why even bother with SQL code? AH! Choice! Kudos to the dev team. You wrote: > On Mon August 4 2003 20:34, Steven Fries wrote: > > 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 growsno 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. > Yes > > So as far as speed, it's negligible either way. Separation of datanow > > that's where it's at.. > Yes. > You are right in both instances, but we were arguing speed. If you read my > initial email on this thread you will see that I said that asking a backend > for information will be _slower_ than consulting an in memory list. Slower is > a relative term. ı never said it was too slow and I never said that you > should not use a DB because of it. I simply argued that if you pick a DB > backend that you do it for the right reasons. Speed is not one of them. You > can argue ram disks, or separate servers until you are blue in the face, but > on identical hardware, especially if it is memory constrained standalone > FreeRdius should be quicker. > This is the mailing list for an Open Source project. Argueing about how one > fast one implimentation or another is is definately on topic. If we get > better code, or better documentation of even a better understanding of how > things work out of the discussion thats great.. > -- > 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 --
Re: Advantages of Using SQL ?
Ok lets make peace :) Everybody argue about something and usually its so difficult to come to a conclusion. Microsoft says windows is good, linux people say linux is better, I say FreeBSD is best :) Anyhow the hardware is so fast and cheap nowadays that we dont need to be so efficient :) It is better to install things the most productive way. Usually it is enough... By the way I would like to finish this with something which I think funny: I just remembered something when I thought about efficient. Microsoft always says the newer version of windows works faster and more efficiently etc. But yet they require faster cpu's and more memory in their system requirements :) When we leave the memory out, I wonder why a more efficient system require faster cpu :) there is a problem in this equation :) Evren Peter Nixon wrote: On Tue August 5 2003 06:37, Evren Yurtesen 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. You could. This again uses more memory, which was one of the things you said you save by using a DB. You can't have it both ways. 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. What is so inefficient about the search algorithm used by FreeRadius. (I have not looked currently) If is IS slow, then once again, we can simply use the "efficient" algorithm from MySQL instead of the one currently in use. 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. You are again basing your arguement on the hypothesis that FreeRadius uses an incredibly inefficient algorithm to search though memory. It would literally have to be several orders of magnitude slower than the search algorithm used by MySQL for them to be _even_ in terms of speed due to disk/context switch/socket/parsing overhead. I simply don't believe that this is the case. If you show me a benchmark that proves this, I will shutup about it, but what you are saying currently just does not make sense. Even if it were true, it would be very simple to fix it (ie. Copy the algorithm that MySQL uses into FreeRadius). 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 10 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 :) 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. It is enough to make a difference :-) Plus if you have 10 users you do not want to reload the users file :) think about reading 10 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. This is a seperate issue. We already agreed on this issue. I never told you otherwise. You cant possible argue that using users file is faster. I can and I am. If you are willing to provide benchmarks that prove otherwise then I will agree that you are right. (And probably rewrite the search algorithm in FR to make it faster :-) Until that time, what you are saying goes against common sense. Its like saying that example B is faster than example A in the following scenario: A) You need to call your girlfriend. You know her number, so you dial it and talk to her. B) You need to call your girlfriend, You don't know her number so you call your secretary and ask her to look it up in the phone book. Your secretary looks up the number, calls you back and give it to you, then you call your girlfriend. Which do you thing is faster?? Bzzzt. WRONG ANSWER. Just because the phone book has a great, wonderfully efficient index, and your secretary is very good at using it, doesn't mean that it's faster than having the number in your own head 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
Re: Advantages of Using SQL ?
On Mon August 4 2003 20:34, Steven Fries wrote: > 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 growsno 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. Yes > So as far as speed, it's negligible either way. Separation of datanow > that's where it's at.. Yes. You are right in both instances, but we were arguing speed. If you read my initial email on this thread you will see that I said that asking a backend for information will be _slower_ than consulting an in memory list. Slower is a relative term. ı never said it was too slow and I never said that you should not use a DB because of it. I simply argued that if you pick a DB backend that you do it for the right reasons. Speed is not one of them. You can argue ram disks, or separate servers until you are blue in the face, but on identical hardware, especially if it is memory constrained standalone FreeRdius should be quicker. This is the mailing list for an Open Source project. Argueing about how one fast one implimentation or another is is definately on topic. If we get better code, or better documentation of even a better understanding of how things work out of the discussion thats great.. -- 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
RE: Advantages of Using SQL ?
Killer analogy :) Jeremy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Peter Nixon Sent: Monday, August 04, 2003 3:24 PM To: [EMAIL PROTECTED] Subject: Re: Advantages of Using SQL ? On Tue August 5 2003 06:37, Evren Yurtesen 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. You could. This again uses more memory, which was one of the things you said you save by using a DB. You can't have it both ways. > 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. What is so inefficient about the search algorithm used by FreeRadius. (I have not looked currently) If is IS slow, then once again, we can simply use the "efficient" algorithm from MySQL instead of the one currently in use. > 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. You are again basing your arguement on the hypothesis that FreeRadius uses an incredibly inefficient algorithm to search though memory. It would literally have to be several orders of magnitude slower than the search algorithm used by MySQL for them to be _even_ in terms of speed due to disk/context switch/socket/parsing overhead. I simply don't believe that this is the case. If you show me a benchmark that proves this, I will shutup about it, but what you are saying currently just does not make sense. Even if it were true, it would be very simple to fix it (ie. Copy the algorithm that MySQL uses into FreeRadius). > 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 10 > 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 :) > > 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. It is enough to make a difference :-) > Plus if you have > 10 users you do not want to reload the users file :) think about > reading 10 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. This is a seperate issue. We already agreed on this issue. I never told you otherwise. > You cant possible argue that using users file is faster. I can and I am. If you are willing to provide benchmarks that prove otherwise then I will agree that you are right. (And probably rewrite the search algorithm in FR to make it faster :-) Until that time, what you are saying goes against common sense. Its like saying that example B is faster than example A in the following scenario: A) You need to call your girlfriend. You know her number, so you dial it and talk to her. B) You need to call your girlfriend, You don't know her number so you call your secretary and ask her to look it up in the phone book. Your secretary looks up the number, calls you back and give it to you, then you call your girlfriend. Which do you thing is faster?? Bzzzt. WRONG ANSWER. Just because the phone book has a great, wonderfully efficient index, and your secretary is very good at using it, doesn't mean that it's faster than having the number in your own head > 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 t
Re: Advantages of Using SQL ?
Hello Do not forget fastuser The fastusers works fats... And can fit a lot of users into the memory... And if I remember correctly, uses hash. And do not forget the radius task is almost a read-only task -= in a normal environment you can not compare an amount of auth requests with an amount of request to change a password... It's funny to hear - but users want to be able to change their password! So what? they will sit and click in broweser/etc to change their password so fast as cisco/whatever sends requests for authentication? I guess user will much often need to be authenticated, then to be able to change his passwd. IMHO. From what I have seen. On 10:24pm, Peter Nixon wrote: > On Tue August 5 2003 06:37, Evren Yurtesen 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. > > You could. This again uses more memory, which was one of the things you said > you save by using a DB. You can't have it both ways. > > > 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. > > What is so inefficient about the search algorithm used by FreeRadius. (I have > not looked currently) If is IS slow, then once again, we can simply use the > "efficient" algorithm from MySQL instead of the one currently in use. > Gregory G. V. --- Any opinions in this posting are my own and not those of my present or previous employers. According Isham Research's Devil's IT Dictionary mainframe is: "an obsolete device still used by thousands of obsolete companies serving billions of obsolete customers and making huge obsolete profits for their obsolete shareholders. And this year's run twice as fast as last year's." - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Advantages of Using SQL ?
On Tue August 5 2003 06:37, Evren Yurtesen 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. You could. This again uses more memory, which was one of the things you said you save by using a DB. You can't have it both ways. > 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. What is so inefficient about the search algorithm used by FreeRadius. (I have not looked currently) If is IS slow, then once again, we can simply use the "efficient" algorithm from MySQL instead of the one currently in use. > 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. You are again basing your arguement on the hypothesis that FreeRadius uses an incredibly inefficient algorithm to search though memory. It would literally have to be several orders of magnitude slower than the search algorithm used by MySQL for them to be _even_ in terms of speed due to disk/context switch/socket/parsing overhead. I simply don't believe that this is the case. If you show me a benchmark that proves this, I will shutup about it, but what you are saying currently just does not make sense. Even if it were true, it would be very simple to fix it (ie. Copy the algorithm that MySQL uses into FreeRadius). > 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 10 > 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 :) > > 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. It is enough to make a difference :-) > Plus if you have > 10 users you do not want to reload the users file :) think about > reading 10 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. This is a seperate issue. We already agreed on this issue. I never told you otherwise. > You cant possible argue that using users file is faster. I can and I am. If you are willing to provide benchmarks that prove otherwise then I will agree that you are right. (And probably rewrite the search algorithm in FR to make it faster :-) Until that time, what you are saying goes against common sense. Its like saying that example B is faster than example A in the following scenario: A) You need to call your girlfriend. You know her number, so you dial it and talk to her. B) You need to call your girlfriend, You don't know her number so you call your secretary and ask her to look it up in the phone book. Your secretary looks up the number, calls you back and give it to you, then you call your girlfriend. Which do you thing is faster?? Bzzzt. WRONG ANSWER. Just because the phone book has a great, wonderfully efficient index, and your secretary is very good at using it, doesn't mean that it's faster than having the number in your own head > 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 swi
Re: Advantages of Using SQL ?
And dont forget that the SQL solution will use hashed indexes, usually even if you don't define them. So yes, small database will be faster as a flat file loaded in memory, but big databases will normally be faster from SQL due to cacheing of the hash and the user data. But then, maybe free radius hashes the user file, so in that case yes, loading a 10 GB user file into memory would be faster, but not particularly efficient or intelligent... On Mon, 4 Aug 2003 12:34:34 -0500 (CDT) Steven Fries <[EMAIL PROTECTED]> wrote: 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 growsno 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 datanow 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 10 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 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 10 users you do not want to reload the users file think about reading 10 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 > > > They do. Of course they do. It is always faster to load data at run time than > > l
Re: Advantages of Using SQL ?
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 growsno 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 datanow 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 10 > 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 > 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 > 10 users you do not want to reload the users file SRC="/images/emoticon14.gif"> think about > reading 10 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 > > > > > > 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???!!! > >
Re: Advantages of Using SQL ?
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 10 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 :) 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 10 users you do not want to reload the users file :) think about reading 10 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 :) 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 wi
Re: Advantages of Using SQL ?
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
Re: Advantages of Using SQL ?
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. 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. 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 :) 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. 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. 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 Evren 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
Re: Advantages of Using SQL ?
On Mon August 4 2003 19:01, Andrea Coppini 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. If that were the case, it would only be because of a bug in FreeRadius. Much more system resources are used by SQL+Radius than just by Radius. -- 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
Re: Advantages of Using SQL ?
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 -- - Graeme Hinchliffe (BSc) Core Team Member Zen Internet (http://www.zen.co.uk) ICQ 3842605 (link) Direct: 01706 900 212 Sales : 0870 6000 971 Fax : 0870 6000 972 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Advantages of Using SQL ?
> 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. Andrea Coppini +356 79 ANDREA (263732) [EMAIL PROTECTED] EMPOWER PEOPLE - THE WORLD IN YOUR HAND iWG (iWORLD GROUP) is a global e-mobile company creating, building and growing new businesses. iWG founders are pioneers in creating multi-billion dollar mobile and Internet businesses in Europe, Asia and the US. The Global Partners include the shareholders Bank of America, Deutsche Bank, Hikari Tsushin, McCaw, PaineWebber/UBS, The Dolphins' Trust, Perikles Trust and the iAA Advisory Network. www.iWG.info www.countryprofiler.com/iWG Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Advantages of Using SQL ?
On Mon August 4 2003 21:53, Evren Yurtesen wrote: > think about it yourself, > > -easy data manipulation, > -reload of freeradius is not needed > -nice web interface dialup_admin > -you can make your own web interface with php easily with sql connectivity. Yes. These are all correct.. > These are what I can think of at the moment. I also think it would be > faster than using users file and freeradius would use less memory since > it doesnt load the whole users file to memory (I think it loads it?!) > if you have many users for example. SQL is also designed for quick data > retrieval so if you plan to have many users than it would give better > performance when the server needs to find one user. Actually, you are wrong on this point I think. FreeRadius _would_ use less memory, that is correct, although memory usage should not be an issue, however using a SQL server as an Authentication backend _must_ be slower than a userlist that is already in memory. Just think about what happens.. FreeRadius with users file: * Request comes in * FreeRadius checks if the user is valid from its copy of the users file in memory * FreeRadius responds to the NAS with allow or deny FreeRadius with DB backend for Authentication: * Request comes in * FreeRadius sends a SQL query to the DB. * DB does an index search for the username * DB loads the usename records from disk into memory * DB Sends the username record back to FreeRadius * FreeRadius responds to the NAS with allow or deny Which do you think will be faster?? > Perhaps you should also ask to yourself, what is the disadvantage? See above. DB backends are good, and save alot of admin, but don't expect them to be faster than a memory scan :-) > Evren > > Patrick wrote: > > hi, > > > > im a freeradius newbie but i was wondering if there are any major > > advantages to running freeradius on an sql auth system or not ? other > > than of course the obvious stuff like being able to replicate the tables > > etc... > > > > Thanks > > P > > > > > > - > > List info/subscribe/unsubscribe? See > > http://www.freeradius.org/list/users.html > > - > 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
Re: Advantages of Using SQL ?
greater ability to manage and scale up. vec - Original Message - From: "Patrick" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, August 04, 2003 2:43 AM Subject: Advantages of Using SQL ? > hi, > > im a freeradius newbie but i was wondering if there are any major advantages > to running freeradius on an sql auth system or not ? other than of course > the obvious stuff like being able to replicate the tables etc... > > Thanks > P > > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Advantages of Using SQL ?
think about it yourself, -easy data manipulation, -reload of freeradius is not needed -nice web interface dialup_admin -you can make your own web interface with php easily with sql connectivity. These are what I can think of at the moment. I also think it would be faster than using users file and freeradius would use less memory since it doesnt load the whole users file to memory (I think it loads it?!) if you have many users for example. SQL is also designed for quick data retrieval so if you plan to have many users than it would give better performance when the server needs to find one user. Perhaps you should also ask to yourself, what is the disadvantage? Evren Patrick wrote: hi, im a freeradius newbie but i was wondering if there are any major advantages to running freeradius on an sql auth system or not ? other than of course the obvious stuff like being able to replicate the tables etc... Thanks P - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Advantages of Using SQL ?
On Mon, Aug 04, 2003 at 10:43:01AM +0200, Patrick wrote: > hi, > > im a freeradius newbie but i was wondering if there are any major advantages > to running freeradius on an sql auth system or not ? other than of course > the obvious stuff like being able to replicate the tables etc... online changes without need to restart the radiusd. Oliver. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Advantages of Using SQL ?
hi, im a freeradius newbie but i was wondering if there are any major advantages to running freeradius on an sql auth system or not ? other than of course the obvious stuff like being able to replicate the tables etc... Thanks P - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html