[Fwd: Re: rlm_perl (threads) performance question]

[Apostolos Pantsiopoulos]

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 at kinetix.gr, support at kinetix.gr
Tel. & Fax: +30 2310556134
Mobile : +30 6937069097
MSN : apant2 at hotmail.com
WWW: http://www.kinetix.gr/
------------------------------------------- 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20071016/1e986b53/attachment.html>