<p dir="ltr"><br>
On 5/06/2014 9:09 PM, "Kostas Zorbadelos" <<a href="mailto:kzorba@otenet.gr">kzorba@otenet.gr</a>> wrote:<br>
><br>
><br>
> Now, this is a nice coincidence, switch in the thread context.<br>
><br>
> I would also like to know performance numbers and seached very briefly<br>
> for RADIUS stress test tools but the most promising I found, radperf, is<br>
> unavailable.<br>
><br>
> ><br>
> >> We are an ISP with around 800k subs and are running 2.1.12 since<br>
> >> that's what comes with RHEL 6.5 and use perl for the slightly more<br>
> >> complex things you can't easily do with unlang.<br>
> >><br>
> >> I was running performance testing against our ldap database last<br>
> >> week using a custom JMeter sampler I built to make the radius calls<br>
> >> using tinyradius as the client. Managed to get up to 760tps where a<br>
> >> transaction was one access request and two accounting starts (so<br>
> >> 2280rps). I suspect that the performance hit was coming from jmeter<br>
> >> as those numbers smashed anything the bngs could throw at us and the<br>
> >> cpu never went above 8% so I am happy enough.<br>
> ><br>
><br>
> Very nice to know, thanks.</p>
<p dir="ltr">Happy to email you the two extra jars you need offline plus some instructions on how to drive it.</p>
<p dir="ltr">Not sure if it's something that would be useful on the wiki or not.</p>
<p dir="ltr">><br>
> > For comparison lightly tuned v3.0.x gets around 22,000-25,000 RPS<br>
> > against the latest version of OpenLDAP with LMDB, so although it may<br>
> > be good enough for your purposes, that represents a huge slow down<br>
> > over what's possible.<br>
> ><br>
> > Even with BDB (properly tuned) you should expect a rate of around<br>
> > 12,000 RPS (though i've not personally tested that).<br>
> ><br>
><br>
> Since we do not have OpenLDAP, but former SUN's JES, I am interested to<br>
> know how you perfomed the tests. Custom developed tool, or anything<br>
> generally available?<br>
><br>
> > As with all RADIUS deployments the problem isn't handling day to day<br>
> > load, it's when your access layer (be it DSLAMs, APs, or Ethernet<br>
> > switches) goes offline and comes back, and you suddenly have to deal<br>
> > with extremely high continuous load.<br>
> ><br>
><br>
> Exactly.<br>
><br>
> Regards,<br>
> Kostas<br>
> -<br>
> List info/subscribe/unsubscribe? See <a href="http://www.freeradius.org/list/users.html">http://www.freeradius.org/list/users.html</a><br>
</p>