[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: poor performance of OpenLDAP vs AD?
Hi all,
I would like to add my two cents to this no doubt interesting
discussion. I think my two cents will be valuable as I am running about
50 instances of OpenLDAP servers in company of huge size with huge
amount of data (per directory).
1) OpenLDAP is rock solid and damned stable. We run it with 100%
availability over years. OpenLDAP delivers really enterprise level of
performance and availability.
2) You just don't need multimaster replication. You can loadbalance over
several LDAP directories via any industry standard loadbalancer. You
update master and propagate changes via slurpd. Believe me, it works in
huge company and with a lot of data. It is just enough!
Howard was in our place giving lectires about LDAP, he will confirm that
I am not BS'ing.
Cheers, vadim tarassov.
On Thu, 2005-07-14 at 08:29 +0200, Tomasz Chmielewski wrote:
> Howard Chu schrieb:
> > Quanah Gibson-Mount wrote:
> >
> >> --On Wednesday, July 13, 2005 2:49 PM +0200 Tomasz Chmielewski
> >> <mangoo@interia.pl> wrote:
> >>
> >> > Recently, when planning to deploy a directory server, I was
> >> > confronted with someone claiming that OpenLDAP performs poorly,
> >> > when compared to Active Directory, and thus, we should choose AD.
> >
> >
> > And I bet they also said that running Microsoft products has a lower
> > Total Cost of Ownership than anything else too.
>
> Yeah it's some of the guys that believe in all that.
>
> But as I'm able to dismiss all his claims, with all I can't.
>
> AD works in a multi-master environment, OpenLDAP doesn't.
>
> We don't really need a multi-master environment, but can a claim that a
> multimaster environment is much more superior over master-slaves model
> in terms of preformance - can this claim be true?
>
> As I studied the multimaster AD replication a bit:
>
> http://www.comptechdoc.org/os/windows/win2k/win2kadrepl.html
>
> and for me, it seems that it can be more efficient, as it would need at
> least one connection less.
> On the other hand, there seems to be much overhead concerned with
> additional data that goes around to keep this multimaster state in sync.
>
>
--
vadim <vadim.tarassov@swissonline.ch>