<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hardware: based on ESX host:<br>
        4 core 2.1GHz processor (have 24 cores to play with)<br>
        8GB Memory (have more as needed)<br>
        CentOS 5.7 x84_64 (latest patches)<br>
        MySQL 5.5.20 - Same VM and supplied by Oracle<br>
        FreeRadius 2.1.12-7 - complied here, with MySQL libraries for
    version 5.5.20<br>
    <br>
    Limitations so far:<br>
        4 million dial-in potential users (16 million gets a bit slow -
    so looking for other improvements)<br>
        In bound transaction rate (sustained mix of 1:1.5 of radius
    authentication:Radius accounting) 2048<br>
        Response time (so far and improving) < 500mS (current gains
    are from reworking MySQL data tables, structures, and indexes)<br>
    <br>
    CPU utilisation is still low (as reported by VSphere) ~15% ie MySQL
    is running well, and so is FR. Packet loss increases to 10% 2.5K
    transactions/sec.<br>
    <br>
    I am looking to use activeMQ to relieve some of the 3ggp
    (3ggp-Location etc.), add enrichment; and then ultimately manage
    quotas with overuse getting PoD. <br>
    <br>
    The activeMQ is on another host (utilisation of the primary network
    interface isn't that high; but will be looking to use a second
    interface, or even using the radius VM to host the activeMQ queue,
    with an additional VM running quota management.<br>
    <br>
    NB Quota is measured in credits, and other systems can charge
    credits - so there isn't a 'fixed' byte usage for radius accounting
    to count down. Also there is another system based on netflow
    managing nearer real time (well 5 minutes) actual data usage.<br>
    <br>
    I've wanted to limit the number of threads, as if the activeMQ
    server fails, I don't want radius to fail (users shouldn't be
    penalised because of poor systems management/setup). It's all a bit
    too open ended for me to feel comfortable with this as a solution as
    it stands.<br>
    <br>
    I'll be testing a local activeMQ server later today, with a view to
    either give it up as a bad idea, or to find some other way (postath
    database processing?).<br>
    <br>
    My feeling is that I've yet to unleash the real power of FR; but
    it's far from obvious to me, as to how to improve MySQL performance
    with FR. Reading others: dumping MySQL (albeit in a MySQL
    configuration -> local file + reload) way seems the next step.<br>
    <br>
    Simon<br>
    <br>
    On 02/14/2012 07:20 AM, Alan DeKok wrote:
    <blockquote cite="mid:4F3A0B3E.90802@deployingradius.com"
      type="cite">
      <pre wrap="">Simon Earthrowl wrote:
</pre>
      <blockquote type="cite">
        <pre wrap=""> FR 2.1.12-1 and 2.1.12-7, but also looked at 3.0.0.
I manage to get 2048 perl threads (assumed from /netstat -ap/ - as I'm
interfacing into Apache's ActiveMQ), then when I hit 2049 threads FR
crashes.
</pre>
      </blockquote>
      <pre wrap="">
  See doc/bugs for how to deal with crashes.

  And 2K threads?  There's something wrong with your architecture if you
need that.  Your backend is VERY slow, or your load is too high, or
you've under-provisioned your machines.

  The biggest mistake is that you're talking about solutions, not
problems.  Using 2K threads is a solution.  Since you haven't specified
what the problem is, there may be OTHER solutions which work better.

  e.g. If you're doing something crazy like using 2K threads, the usual
response is "don't do that"

  Alan DeKok.
-
List info/subscribe/unsubscribe? See <a class="moz-txt-link-freetext" href="http://www.freeradius.org/list/users.html">http://www.freeradius.org/list/users.html</a>
</pre>
    </blockquote>
  
<a href="https://twitter.com/EseyeM2M" class="twitter-follow-button" data-show-count="false">Follow @EseyeM2M</a>
<script>!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0];if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src="//platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs");</script><br>
Surface mount embedded SIMs in stock - adapter kit available for testing in a SIM socket<br>
"Smart Metering Technology of the Year Award 2012 - Shortlisted' <br>
Eseye Ltd , Company No:  06397669  - Surrey Technology Centre, Guildford, UK   +44 1483 685200
</body>
</html>