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.