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. > 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 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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html