Re: [Fwd: Re: rlm_perl (threads) performance question]
I have a clue, maybe your client is not able to do more requests or your configuration on client side is wrong. Best Regards, Boian Jordanov SNE Orbitel - Next Generation Telecom tel. +359 2 4004 723 tel. +359 2 4004 002 On Oct 17, 2007, at 9:17 AM, Alan DeKok wrote: Apostolos Pantsiopoulos wrote: Well, yes that has been my main concern I must admit... because I have seen so many replies in the mailing list "urging" people to make the backend DB faster (and concentrating on that aspect alone when the server performs poorly). There are many factors to consider in tuning a system. A RADIUS server all by itself can handle 5k requests/s, if it doesn't access DB's or any files. A stand-along DB client can do 1000's of reads/s all by itself. The combination of the two does NOT necessarily get the best of both... i.e. 1000's of reads/s through RADIUS. Interaction effects mean that the maximum throughput is LESS than the maximum throughput of each piece in isolation. Find out what else is stopping the server from processing requests. Is there ANYTHING you have configured other than your Perl script? If so, that may be the issue. I''ll re-check it. Run "cachegrind" to see where all of the CPU time is spent. It won't count sleeping (or waiting for network activity), so the times may be somewhat misleading. But it may help. 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: [Fwd: Re: rlm_perl (threads) performance question]
Apostolos Pantsiopoulos wrote: > Well, yes that has been my main concern I must admit... because I have > seen so many replies in the mailing > list "urging" people to make the backend DB faster (and concentrating on > that aspect alone when the server performs poorly). There are many factors to consider in tuning a system. A RADIUS server all by itself can handle 5k requests/s, if it doesn't access DB's or any files. A stand-along DB client can do 1000's of reads/s all by itself. The combination of the two does NOT necessarily get the best of both... i.e. 1000's of reads/s through RADIUS. Interaction effects mean that the maximum throughput is LESS than the maximum throughput of each piece in isolation. >> Find out what else is stopping the server from processing requests. >> Is there ANYTHING you have configured other than your Perl script? If >> so, that may be the issue. >> > I''ll re-check it. Run "cachegrind" to see where all of the CPU time is spent. It won't count sleeping (or waiting for network activity), so the times may be somewhat misleading. But it may help. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: [Fwd: Re: rlm_perl (threads) performance question]
First of all thanks for your prompt replies Alan DeKok wrote: Apostolos Pantsiopoulos wrote: I did that. Actually it was the first thing I did. I got the same result. Also, the server does a LOT more than just running Perl. You are measuring the time taken to run your Perl scripts. The time taken to process a request can be VERY different. I just benchmarked the "internal" script just to see if the DB is the bottleneck. It is not. That's not what I meant. The server has "RADIUS" work to do, on top of running your Perl code. That means that there's less time to run your Perl code, because the server is busy managing the "RADIUS" side of things for you. I see. EVERY query did not take more than 0.03 secs ( thrice the size of the mean time) i.e. if you don't run RADIUS, you don't see any overhead from RADIUS. Yes, I agree that they are competing for resources (and in this case the DB is the only resource, really). But when my server gets choked up shouldn't we expect to see big response times during the benchmark of the perl module? You are stuck on the idea that your Perl module is all that the server is doing. It's not. Well, yes that has been my main concern I must admit... because I have seen so many replies in the mailing list "urging" people to make the backend DB faster (and concentrating on that aspect alone when the server performs poorly). I have all the other modules turned off. (e.g. running the same queries from an outside program I can get about 200 queries/sec from the DB ... and that program does NOTHING other than run DB queries. So?\ Point. , when my radiusd reaches the 50 r/s limit the DB idles at 10-24 q/s, so the DB does not seem to be the problem) Find out what else is stopping the server from processing requests. Is there ANYTHING you have configured other than your Perl script? If so, that may be the issue. I''ll re-check it. Alan DeKok. Thanks again - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: [Fwd: Re: rlm_perl (threads) performance question]
Apostolos Pantsiopoulos wrote: > I did that. Actually it was the first thing I did. I got the same result. >> Also, the server does a LOT more than just running Perl. You are >> measuring the time taken to run your Perl scripts. The time taken to >> process a request can be VERY different. > > I just benchmarked the "internal" script just to see if the DB is the > bottleneck. It is not. That's not what I meant. The server has "RADIUS" work to do, on top of running your Perl code. That means that there's less time to run your Perl code, because the server is busy managing the "RADIUS" side of things for you. > EVERY query did not take more than 0.03 secs ( thrice the size of the > mean time) i.e. if you don't run RADIUS, you don't see any overhead from RADIUS. > Yes, I agree that they are competing for resources (and in this case the > DB is the only resource, really). > But when my server gets choked up shouldn't we expect to see big > response times during the benchmark > of the perl module? You are stuck on the idea that your Perl module is all that the server is doing. It's not. > (e.g. running the same queries from an outside > program I can get about 200 queries/sec from the DB ... and that program does NOTHING other than run DB queries. So? > , when my radiusd reaches the 50 r/s limit the DB idles at 10-24 q/s, so > the DB does not seem to be the problem) Find out what else is stopping the server from processing requests. Is there ANYTHING you have configured other than your Perl script? If so, that may be the issue. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
