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/ -------------------------------------------