rlm_perl (threads) performance question
aland at deployingradius.com
Tue Oct 16 13:42:33 CEST 2007
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
I don't think so. The start/stop requests do different things, so
it's not surprising that they have different mean times.
> 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.
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.
> 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.
> 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.
i.e. the mean time per request and the request rate are two VERY
> 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...
More information about the Freeradius-Users