[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ldap load measuring and reproduction tools


"Quanah Gibson-Mount" wrote: 

You really leave out a lot of information that might be helpful.

1) How many entries are in your poorly designed tree? :P 
We have about 180000 entries (dn's)


2) What version of OpenLDAP are you using?

Well, actually it's not OpenLDAP we are running. The reason I used the OpenLDAP mailing list was that I was not really sure where to even start, and since a lot of general and real-world-practical LDAP knowledge is available on this list, I thought it might be just as good a place to start as anywhere else. The idea was to gather as much information as possible, hoping/assuming that it would prove to be either 'generically applicable', or at least 'translatable' to my specific scenario and situation. So, at the risk of either getting kicked of the list or everyone going radio-silent on me, here is the configuration we are running :

OS: AIX 5.2
LDAP Server: IBM SecureWay Directory 3.2.2
Backend: IBM DB2 7.1

Server model: IBM 7038-6M2
RAM: 2GB
1 Single CPU
2 1GB Fibre Channel SAN disks, connected to 2 IBM ESS 800's ('Shark')
10 multi-path 17Gb disks (mirrored)



Since I (and you apparently) have no idea what sort of BIND or SEARCH rate your single replica is under, it is hard to know what your requirements are, and I understand you are trying to gather that data.
Well here are some selective "cn=monitor" results. The numbers are measured over an interval of 60 seconds

opscompleted: 755
searchescompleted: 488

Which I guess means that we are seeing about 12 'operations' per second, and about 8 searches per second. Unfortunately this does not say anything about the amount of updates were seeing, and the 'cn=monitor' does not appear to provide that type of information.


Also, the number of replica's to master is an interesting question. It will mostly depend I guess on how many writes you experience in a single day. Again, the information you've provided here is minimal, but unless your master is in a constant state of change, I'd think it'd be able to hold up just fine even with a large number of replicas.


Ok, so what you are saying is that it is very unlikely that one will hit bottlenecks that are caused by the design of the software, or the algorithms used in the software ?




Sincerely,


John Smith.