On 11 Feb 2015, at 10:35, Phil Mayers <p.mayers@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@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2