LDAP Accounting

Kostas Kalevras kkalev at noc.ntua.gr
Tue Dec 11 12:31:16 CET 2012


On 11/12/2012 11:56 πμ, Phil Mayers wrote:
> On 12/10/2012 03:27 PM, John Dennis wrote:
>> On 12/09/2012 07:33 PM, Arran Cudbard-Bell wrote:
>>> Just pushed up a few patches to add LDAP accounting.
>>
>> Just out of curiosity why are we adding support for "worst practice",
>> shouldn't we be encouraging "best practice" via the choice of supported
>> configurations?
>>
>> Maintaining accounting data in LDAP is an abuse of the LDAP design goals
>> of "frequent lookup, infrequent modification". Databases were designed
>> for the type of data management that radius accounting involves,
>> directories were not. Accounting should be in a database, not a
>> directory. Directories were designed to solve different problems.
>
> This is a bit OT, but I'm honestly curious here...
>
> I've heard this sort of general statement about directories 
> (specifically LDAP) being suitable for read-heavy workloads, and SQL 
> being suitable for read/write-heavy, for well over 15 years now.
>
> No-one has ever adequately explained to me *why* sending an LDAP write 
> op PDU is somehow different than sending an LDAP read op PDU.
>
> It may be that all or most LDAP *implementations* are relatively slow 
> at writes, but if so, it doesn't follow that this *must* be the case.
>
> Obviously writes are slower than reads in LDAP, but that's true of 
> almost any datastore backed by permanent storage. However, having done 
> mass/bulk LDAP updates to OpenLDAP (and on older versions) I've found 
> it pretty snappy. So I'd love to know why this is an "abuse" any more 
> than using any other protocol in unanticipated-but-compliant ways.

It's not an abuse but mainly not 'best-practice'. A well configured LDAP 
server with enough cache memory will be bottlenecked by memory and 
network speed and not by underlying I/O. A frequent writes strategy 
invalidates most of these performance gains since an entry write will 
invalidate entry and database cache entries.


>
>
> Cheers,
> Phil
> -
> List info/subscribe/unsubscribe? See 
> http://www.freeradius.org/list/devel.html


-- 
Kostas Kalevras
Network Operations Center
National Technical University of Athens
http://kkalev.wordpress.com
http://kkalev4economy.wordpress.com



More information about the Freeradius-Devel mailing list