[Fwd: Re: rlm_perl (threads) performance question]
Alan DeKok wrote:
Apostolos Pantsiopoulos wrote:
I am using the rlm_perl module for accounting purposes.
...
The results I get (after 2-3 k requests) are these :
Mean time for acct start : 0.005 secs Mean time for acct stop : 0.01 secs
Since there is a 1:1 ratio of start/stop requests I guess that we can say that for each request (regardless of its type) I should get a mean of 0.0075 secs.
I don't think so. The start/stop requests do different things, so it's not surprising that they have different mean times.
Yes it is not surprising, indeed. I just used them to find an approximate value for a "request" mean time so that we wouldn't have to distinguish between start and stop. That is not the problem though. My stop script does a lot more then my start, so that's explainable...
And this in turn should be giving about 130 req/sec.
But I am not getting this kind of performance. I know that there is a handling overhead for each request. I don't know the exact percentage of this overhead but for simplicity's sake lets be pessimistic and consider it to be about 30%.
You can measure the performance of the server externally, via a client. Send the server a request, and wait for a response. Take the difference, and that's the time required to process a request.
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. EVERY query did not take more than 0.03 secs ( thrice the size of the mean time)
Now the performance should be something like 80 req/sec. But I am not getting this kind of performance either. In fact, as soon as my main radius reaches a number of 50 req/sec my NAS starts sending requests to my backup radius.
Likely because the RADIUS server is getting blocked, and not responding to requests. That's usually because of a slow database.
See above...
If every perl clone can complete each request in X secs shouldn't 32 clones complete 1/X*32 requests per second? Or something similar to that?
No. They may be competing for resources. The request rate is affected strongly by requests that take a long time. In contrast, the mean time per request is strongly affected by a large number of requests that take a small amount of time.
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? (e.g. running the same queries from an outside program I can get about 200 queries/sec from the DB , 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)
i.e. the mean time per request and the request rate are two VERY different metrics.
The problem does not seem to be the database. I made a simple program that uses the exact same code as my radius perl script does and I can get this kind of performance easily.
There may be other things going on...
Alan DeKok.
Is there a way to "monitor" how many threads are actually at work (busy) at a given time? That could be really helpful... -- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com Support Center email: apant@kinetix.gr, support@kinetix.gr Tel. & Fax: +30 2310556134 Mobile : +30 6937069097 MSN : apant2@hotmail.com WWW: http://www.kinetix.gr/ -------------------------------------------
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.
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
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.
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
Hi, Does the latest 2.0-pre of freeradius support parsing of wimax VSA attributes ? If it is not (I feel it is not supported yet, as i could not see any dictionary for wimax vsa), is there any plans or work in progress to implement it ? Another question is, does the wimax forum dictate what to be done with these attributes in radius server ? Thanks Katro ___________________________________________________________ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/
katro kar wrote:
Does the latest 2.0-pre of freeradius support parsing of wimax VSA attributes ?
No.
If it is not (I feel it is not supported yet, as i could not see any dictionary for wimax vsa), is there any plans or work in progress to implement it ?
There are no plans to support it. i.e. If someone sends in a patch, or supports the feature via some other method, then it will go in.
Another question is, does the wimax forum dictate what to be done with these attributes in radius server ?
Yes. The WiMAX NWG specification has detailed requirements. You need to be a member of the WiMAX forum to obtain the specifications, I believe. Alan DeKok.
Another question is, does the wimax forum dictate what to be done with these attributes in radius server ?
Yes. The WiMAX NWG specification has detailed requirements. You need to be a member of the WiMAX forum to obtain the specifications, I believe.
Since v1, the specifications are freely available on WiMAX forum web site: http://www.wimaxforum.org/technology/documents/ Geoff. _____________________________________________________________________________ Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail
participants (5)
-
Alan DeKok -
Apostolos Pantsiopoulos -
Boian Jordanov -
Geoffroy Arnoud -
katro kar