Hi John,

I tried with 10000 users and there was no problem. But maybe it is
related to auto-completion. Please give me some more days to test this.


Best regards

Roland



On 15.09.2014 15:23, John Maher wrote:
> Hi Roland,
> 
> I already have a high level of logging (stats) enabled, so, I looked
> at the ldap searches again. The search that takes the longest (the
> last search) is essentially this:
> 
> ldapsearch -x -LLL -H ldapi:/// -b ou=people,dc=cns
> 'objectClass=inetOrgPerson' departmentNumber title employeeType
> 
> This command takes 0.54 seconds, so I'm pretty confident at this point
> that ldap itself is not presenting a performance problem.
> 
> During the search (after I have clicked the edit icon for a user),
> apache is essentially the only process using the cpu. It's taking 100
> percent of the cpu for the entire 30 seconds before there is an unbind
> and close result for slapd.
> 
> I have a vanilla install of apache. If any of this information can
> help you direct me what to do I would be delighted.
> 
> Thanks for you help.
> 
> John
> 
> On 09/14/2014 03:08 PM, Roland Gruber wrote:
>> Hi John,
> 
>> On 12.09.2014 20:08, John Maher wrote:
>>> It's possible that the LDAP server is the bottleneck, but I
>>> don't understand why editing a single user would need to start
>>> with a search of all users. (Although the check for duplicates
>>> would explain that I guess.) Can you direct me to the code that
>>> constructs the LDAP searches, or tell me what searches LAM is
>>> performing. I have yet to create a search using the ldapsearch
>>> utility that lasted more than a few seconds.
> 
>> I think the best approach is to turn on LDAP logging like described
>> at the end of this page. This is much easier than trying to get the
>> various queries out of the code.
> 
> 
>> https://www.ldap-account-manager.org/static/doc/manual/api.html
> 
> 
> 
> 
>> ------------------------------------------------------------------------------
> 
> 
> Want excitement?
>> Manually upgrade your production database. When you want
>> reliability, choose Perforce Perforce version control. Predictably
>> reliable. 
>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> 
> 
> 
> 
>> _______________________________________________ Lam-public mailing
>> list [email protected] 
>> https://lists.sourceforge.net/lists/listinfo/lam-public
> 
> 
> 
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Lam-public mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/lam-public
> 

Attachment: signature.asc
Description: OpenPGP digital signature

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Lam-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lam-public

Reply via email to