Misc question about LDAP and admin stuff

[Per-Olov Sjöholm]

On Wednesday 27 July 2005 14.20, Kevin Menard wrote:
> Hi Igor,
>
> On Jul 27, 2005, at 6:59 AM, Igor Brezac wrote:
> >> Hmmm. I do know understand your LDAP performance comment.... Why
> >> should you
> >> write often to LDAP in a scenario like this??? You configure the
> >> attributes
> >> rarely  and then read them often. I can only see writes during
> >> user password
> >> change or any other admin changes of user attributes. *One* of the
> >> golden
> >> rules to use LDAP is to have *many* more reads for each write
> >> (example
> >> 1000:1). I work with LDAP in my daily work. But I maybe
> >> missunderstood you...
> >
> > You said you wanted quotas stored in ldap, this will require
> > frequent writes to ldap
>
> I'm going to chime in here if you don't mind, since several years ago
> I began work on LDAP quota look-ups.  Unfortunately, I never
> completed the work, although the design discussions between Larry and
> me should still be in the archives.  Back then we felt, and I still
> feel now, that you would only want to store the actual quota
> threshold in LDAP.  There is no reason to store how much of the
> mailbox is actually being used in LDAP, since this is in information
> that is practically useless outside of Cyrus.  This would result in
> read-only operations from the LDAP backend, unless a user's quota is
> to be changed (which should be an infrequent operation).

Yes... I agree with you Kevin. I do not see the frequent writes in LDAP for 
quotas ...Especially not if it has a good design (which we of course must 
have). Not using your approach and updating LDAP very often about mailbox 
usage can of course give a performance penalty (which maybe is the approach 
Igor was thinking of). I do not see huge problems to store other Cyrus 
related data in LDAP either if the Cyrus developers want to make it possible. 
It will mostly be reads unless something changes which is infrequent.

But let's drop this discussion now as it seems to have turned into a 
performance discussion which it was not in the original post. But others can 
continue the thread if they are interested and want to discuss performance... 
Many posts will give good stuff to dig in when we search for info ;-)

Tnx for all good input from Igor and others.
/Per-Olov
-- 
GPG keyID: 4DB283CE
GPG fingerprint: 45E8 3D0E DE05 B714 D549 45BC CFB4 BBE9 4DB2 83CE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : https://lists.andrew.cmu.edu/mailman/private/info-cyrus/attachments/20050730/278d0d42/attachment.bin