[phpldapadmin] [ phpldapadmin-Bugs-3391046 ] Loading entries with many attributes is very slow

Bugs item #3391046, was opened at 2011-08-14 04:36
Message generated for change (Comment added) made by wurley
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=498546&aid=3391046&group_id=61828

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Roland Gruber (gruberroland)
Assigned to: Nobody/Anonymous (nobody)
Summary: Loading entries with many attributes is very slow

Initial Comment:
Hi Deon,

opening an LDAP entry that has lots of attributes (about 100) takes about 10 seconds on a recent PC. The problem is the sorting.
PLA calls Attribute->getName() and real_attr_name() several 100,000 times. This is caused by ~100,000 calls of getFriendlyName().

The source seems to be in sortAttrs($a,$b) that does not use cached values. Probably, it would be even better to simply get a list of all attribute friendly names first and then do a simple sorting on them (and no usort at all).

Unfortunately, I do not know enough about the code to provide a patch. I hope that my explanations help you to fix this.


Best regards

Roland

----------------------------------------------------------------------

>Comment By: Deon George (wurley)
Date: 2011-10-06 11:08

Message:
Roland et all,

See if patch #059b83b fixes this.

If it doesnt, can you attach an LDIF of a bad case... (and re-open).

----------------------------------------------------------------------

Comment By: Roland Gruber (gruberroland)
Date: 2011-09-11 03:26

Message:
Exactly, it is the number of attributes and not the number of entries.
The problem is the sorting.

----------------------------------------------------------------------

Comment By: Adam Thompson (athompso)
Date: 2011-09-09 01:21

Message:
I don't have as extreme a case as Roland, but I've also noticed this.  Not
the # of LDAP entries in a container, but the number of distinct key/value
pairs (attributes) on a single LDAP entry makes opening that specific DN
quite slow.  My server is sometimes CPU-starved, and I can see the
difference between a DN with ~20 attrs and ~100 attrs at that time.

----------------------------------------------------------------------

Comment By: Deon George (wurley)
Date: 2011-09-08 22:45

Message:
Hi Roland,

I'm not sure I follow you? On my test server (the demo site), I have a few
branches with 1000+ entries, and it takes about 3 seconds for me (to expand
a branch on the tree)... Is this the scenario you are talking about?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=498546&aid=3391046&group_id=61828

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
______________________________________
phpLDAPadmin development mailing list.
To unsbuscribe: https://lists.sourceforge.net/lists/listinfo/phpldapadmin-devel
http://phpldapadmin.sourceforge.net/