<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
Alan DeKok wrote:
<blockquote cite="mid:4714A3A9.9010807@deployingradius.com" type="cite">
<pre wrap="">Apostolos Pantsiopoulos wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I am using the rlm_perl module for accounting purposes.
</pre>
</blockquote>
<pre wrap=""><!---->...
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
I don't think so. The start/stop requests do different things, so
it's not surprising that they have different mean times.
</pre>
</blockquote>
Yes it is not surprising, indeed. I just used them to find an
approximate value for a "request" mean time<br>
so that we wouldn't have to distinguish between start and stop. That is
not the problem though.<br>
My stop script does a lot more then my start, so that's explainable...<br>
<blockquote cite="mid:4714A3A9.9010807@deployingradius.com" type="cite">
<pre wrap=""> </pre>
<blockquote type="cite">
<pre wrap="">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%.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
I did that. Actually it was the first thing I did. I got the same
result. <br>
<blockquote cite="mid:4714A3A9.9010807@deployingradius.com" type="cite">
<pre wrap=""> 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.
</pre>
</blockquote>
<br>
I just benchmarked the "internal" script just to see if the DB is the
bottleneck. It is not.<br>
EVERY query did not take more than 0.03 secs ( thrice the size of the
mean time)<br>
<blockquote cite="mid:4714A3A9.9010807@deployingradius.com" type="cite">
<pre wrap=""> </pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
Likely because the RADIUS server is getting blocked, and not
responding to requests. That's usually because of a slow database.
</pre>
</blockquote>
See above...<br>
<blockquote cite="mid:4714A3A9.9010807@deployingradius.com" type="cite">
<pre wrap=""> </pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
<br>
Yes, I agree that they are competing for resources (and in this case
the DB is the only resource, really).<br>
But when my server gets choked up shouldn't we expect to see big
response times during the benchmark<br>
of the perl module? (e.g. running the same queries from an outside
program I can get about 200 queries/sec from the DB<br>
, 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)<br>
<br>
<blockquote cite="mid:4714A3A9.9010807@deployingradius.com" type="cite">
<pre wrap=""> i.e. the mean time per request and the request rate are two VERY
different metrics.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
There may be other things going on...
Alan DeKok.
</pre>
</blockquote>
Is there a way to "monitor" how many threads are actually at work
(busy) at a given time?<br>
That could be really helpful...<br>
<br>
<pre class="moz-signature" cols="72">--
-------------------------------------------
Apostolos Pantsiopoulos
Kinetix Tele.com Support Center
email: <a class="moz-txt-link-abbreviated" href="mailto:apant@kinetix.gr">apant@kinetix.gr</a>, <a class="moz-txt-link-abbreviated" href="mailto:support@kinetix.gr">support@kinetix.gr</a>
Tel. & Fax: +30 2310556134
Mobile : +30 6937069097
MSN : <a class="moz-txt-link-abbreviated" href="mailto:apant2@hotmail.com">apant2@hotmail.com</a>
WWW: <a class="moz-txt-link-freetext" href="http://www.kinetix.gr/">http://www.kinetix.gr/</a>
-------------------------------------------
</pre>
</body>
</html>