Minor but fun changes today

[Arran Cudbard-Bell]

> On 11 Feb 2015, at 10:35, Phil Mayers <p.mayers at IMPERIAL.AC.UK> wrote:
> 
> On 10/02/15 22:05, Alan DeKok wrote:
>> After some discussion, I moved the REQUESTs to using a talloc pool.
>> i.e. it allocates a 32K chunk of memory for reach request, and then
>> allocates REQUEST, RADIUS_PACKET, VALUE_PAIR, etc. within that.  If
>> the pool runs out of memory, talloc() will fall back to using malloc.
>> So there’s no downside to this.  We’ve made a few other minor
>> changes, too.
>> 
>> Preliminary performance tests show a 35% decrease in time (clock
>> cycles, via valgrind) to process the default configuration, with one
>> user:
> 
> Cool. I was going to suggest a talloc_pool() for REQUEST's a while back but never got round to doing any measurement.
> 
> I guess the pool size could be a global but it's almost certainly unnecessary - most requests won't be around for long enough for it to matter.

It'd be a bit of a pain to keep track TBH. You can use a single pool because of thread safety issues, so you'd need to keep track of the number of requests allocated.

What would be great is if talloc tracked high/low water marks, in terms of pool memory actually allocated. That way the server could automatically adjust allocations based on the stats generated when the request was freed.

> Glad to hear it does make a difference - nice going!

In a real world test with a moderately complex config, authenticating against OpenLDAP 2.4 we measured about a 5.2% increase in overall performance, which is actually very good for 6 hours of Alan's time :)

This is the low hanging fruit though, for bigger gains re-architecting is likely required.

-Arran

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 872 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20150211/d4ff6193/attachment.sig>