On Thu, 2008-01-24 at 14:50 -0800, Quanah Gibson-Mount wrote:
But basically, have you read over the information on understanding your system requirements? I.e., how to properly tune DB_CONFIG and slapd.conf?
I've read the OpenLDAP performance tuning stuff at http://www.openldap.org/doc/admin24/tuning.html#Performance%20Factors, but I do not yet have access to the boxes in question so I can't say anything about the specifics of the configuration, etc....
Updates -> master is always recommended. You can set up multi-master with 2.4, but it will be slower than a single master scenario. The general best practice for fail over is to have a primary master that receives writes, and a secondary master that is getting the updates, and will take over via fail-over mechanisms if the primary goes down, becoming the new primary.
Good to know. Do you have any sense for the kinds of performance differences you'd typically see in a multi-master versus master/backup master scenario? If it's just a typical 10% performance hit, we might prefer to go with a multi-master configuration anyway (well, once we upgrade to 2.4.something), but if it's considerably larger then we might want to think again.
RAM is probably the most important, but you also will want fast disks, proper partitioning of the logs separate from the database and logs, and I recommend a non-journaling filesystem. 2 or more cores is also useful. Unfortunately I don't really see enough information from your end (yet) to really say much beyond that.
Also good to know. I'm assuming they've already done at least most of this stuff, but I'll have to wait until I can get on the boxes and start looking around to be sure.
On the SunFire x4100 servers I used to have, I could easily obtain some 23,000+ reads/second with OpenLDAP 2.3 on a single server.
But that's reads only, right? Do you have any sense for what kind of performance you might see in a balanced 50/50 or even a write-heavy environment?
How about the ultimate maximum distribution scenario, where you put an LDAP slave on virtually every major LDAP client machine?
Seems like major overkill to me, unless you are getting hundreds of thousands of reads/second.
At this stage, I'm not making any assumptions. ;-)