Question

I have alot of custom work implemented to mimic our Active Directory structure as TWiki groups. In doing so, there are around 115 groups. Because of the unique implementation and AD structure (multiple CNs for users), LDAP contrib is not an option.

Because I have so many groups, I am seeing around a 2-second delay for every topic to load. I assume it is because of the underlying ACL checking because only TWiki Admins do not see this delay.

Is there anything that I can do to remove this delay?

Environment

-- JosephMecca - 11 Sep 2008

Answer

If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.

presumably your best bet is to add LDAP caching so requests are not made to the AD server every twiki request?

-- SvenDowideit - 12 Sep 2008

Sven, thanks for replying so quickly. I have a process which runs on the server each morning. This process queries AD, based on configurable parameters, such as containers to search and can handle multiple containers which house our groups. It then creates the GroupNameGroup.txt files, based on an empty group template and populates it with the wikinames for each group. All of the files are located in the twiki/data/Main directory on the server. TWiki never goes to LDAP, it is all done via this process, which is outside of TWiki.

It seems that just having a large number of TWiki groups is adding this performance hit, not querying LDAP. How can this be improved?

-- JosephMecca - 15 Sep 2008

If you have alot of users and groups, I would suggest using the LdapContrib (which does do cacheing as i understand it), or HTTPDUserAdminContrib, which I wrote for larger scale twiki's.

-- SvenDowideit - 15 Sep 2008

Closing after more than 30 days. Please reopen with more details if needed...

-- PeterThoeny - 06 Nov 2008