nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Server performance horrendous after enabling LDAP

Bill Klish

MediaBin 4.5.3
Windows 2003 Server EE SP1
MS SQL Server 2000 SP4

MediaBin is one host, SQL server is a separate host and IIS/Deployment Agent is the 3rd host on the same LAN segment.

We were running our servers just using windows authentication across our AD domains, but switched to LDAP tonight.

The good news, it still works to login as our old user accounts, and takes about 3 seconds for the asset and container list to show up on the web client.

If I use my same user id and login using the LDAP domain, it takes minutes for me to see the folders or assets.

This is what is in the Net log:


02/12/08 22:29:53 ConnId:7 User xxxxx logged in (Session#67)
02/12/08 22:29:53 ConnId:7 Session#:67 Protocol:TCP/IP User "xxxxx" logged on.
02/12/08 22:29:53 ConnId:8 Session#:67 (CR5) Got request GetContainerRequest.

02/12/08 22:30:54 ConnId:8 Session#:67 Processed request GetContainerRequest.  Took 61109ms
02/12/08 22:30:54 ConnId:7 Session#:67 (CR2) Got request CGetTasksRequest.
02/12/08 22:30:54 ConnId:7 Session#:67 Processed request CGetTasksRequest.  Took 343ms
02/12/08 22:30:54 ConnId:8 Session#:67 (CR4) Got request CGetPropertyValueRequest.
02/12/08 22:30:54 ConnId:8 Session#:67 Processed request CGetPropertyValueRequest.  Took 0ms
02/12/08 22:30:54 ConnId:7 Session#:67 (CR3) Got request CGetMetaDataCatalogRequest.
02/12/08 22:30:54 ConnId:7 Session#:67 Processed request CGetMetaDataCatalogRequest.  Took 15ms
02/12/08 22:30:54 ConnId:8 Session#:67 (CR1) Got request CGetMetaDataCatalogRequest.
02/12/08 22:30:54 ConnId:8 Session#:67 Processed request CGetMetaDataCatalogRequest.  Took 0ms
02/12/08 22:30:54 ConnId:7 Session#:67 (CR5) Got request CGetPropertyValueRequest.
02/12/08 22:30:54 ConnId:7 Session#:67 Processed request CGetPropertyValueRequest.  Took 0ms
02/12/08 22:30:55 ConnId:8 Session#:67 (CR2) Got request GetContainersInContainerRequest.

We had a packet sniffer active on the LDAP server and the user bind request was near instantaneous.

What is going on that would cause this slow down?

Find more posts tagged with

Comments

Bill Klish

I have an update.

If I add LDAP\xxxx as a MBAdmin, I get good performance in the web client.

Is this just an issue for users who have no permissions to anything, MediaBin does a full scan of all folders to show a "guest" user?

We were about to migrate all of our permissions to LDAP\x but noticed this awful performance and were worried.

It seems to be really slow in enterprise manager still. I know we have a lot of activity going on now with Deployment Agent schedules, but would expect things to be a little better.

I tried adding 2 LDAP users to the MBAdmin group in enterprise manager and that seemed to freeze too:


02/12/08 23:26:52 ConnId:26 Session#:2 Processed request CAddGroupMemberRequest.  Took 21500ms
02/12/08 23:26:52 ConnId:25 Session#:2 (CR1) Got request CGetGroupsRequest.
02/12/08 23:27:40 ConnId:15 Determining User Privileges
02/12/08 23:27:40 ConnId:25 Session#:2 Processed request CGetGroupsRequest.  Took 48313ms
02/12/08 23:27:40 ConnId:26 Session#:2 (CR6) Got request CAddGroupMemberRequest.
02/12/08 23:28:07 ConnId:26 Session#:2 Processed request CAddGroupMemberRequest.  Took 26641ms
02/12/08 23:28:07 ConnId:25 Session#:2 (CR2) Got request CGetGroupsRequest.

msrinivas

If you add users to MBPAdmin group then there is no check performed on the folder permissions. If they are not part of that then it recursively checks folder permissions.

If you have a large tree and have set your top level folders to have no access then you would see such login performance issues.

I believe there are some improvements to this in the latest version. In the interim the following KB might be helpful.

https://support.interwoven.com/kb/kb_show_article2.asp?ArticleID=56585

Bill Klish

The customer has 25 top level folders, which I wouldn't consider a lot of folders. Most of the top level folders have permission exclusions on them, so that when I log in as an LDAP, non MBPAdmin user I only see 3 out of 25 after waiting about 2 minutes.

Did we need to change anything on the database or IIS/Deployment Agent servers? It didn't mention anything about that in the manual. I did see something mentioned about needing a different kind of license. We didn't switch our license.

It looks like we should have just went ahead and migrated the users with the migration script provided in another MB KB article like we planned. It seems the issue is with "Guest" users and not users who have permissions. However, even users in the old AD domain groups had issues last night.

Per the article:
- We run index maintenance from the SQL Server side every night at 2:00 am every night. Is this article speaking about the MediaBin or SQL Server index maintenance. From the enterprise manager, we reindex MediaBin once a week. I did see a few deadlock issues when I was looking at the logs last night.
- We have 4 GB of RAM on the MB server. The MBPw32 process is taking up 53,652K
- Deleted items are cleaned once a week. I checked and there is 1 empty folder in there and 1832 assets.
- We do not have that cache setting in the MBSettings table. It is not clear what the value should be. The example shows 30000, and states it should be a number larger than the number of top level folders. We have 25, should it be 25 * 1000 or some other factor, or just 26. This is unclear.
- It is just as slow in the other clients and the MB Enterprise Mgr
- There are lots of custom metadata fields that we have defined and set on these assets. We have 68 editable metadata fields. Not all are set on all assets.

msrinivas

Since you said that you are eventually able to login using LDAP credentials I would rule out any license issues.

Here are some words from engg. about MB security model:

"MediaBin permits a user to access a child folder of a parent folder to which that user has NO ACCESS permissions. The clients provide a navigation path to the child folder from the UI by exposing the complete tree. When a user logs in, the web client opens the root container and displays its child containers with a + or - to designate if the child containers have children. To create this display, the web client asks the server to return all child containers of the root and all child containers for each child container under the root. The server determines what containers a user can see. To make this determination, that user's permissions are examined for a folder. If that folder has any permissions besides NO ACCESS, that folder is returned. Otherwise, the server must inspect folders under that one, recursively to see if the user has permissions to any folder in the tree. If the tree is quite deep, this is what takes quite a long time to do and what is causing the login delay. For admins, they should not see the issue because they have access to all folders all the time."

Currently all your LDAP users who have not been set up in MB have NO ACCESS and that is causing the issue. To start off I would set up a few users and see if there is better performance. If not then we might be looking at other things. Make sure your net.log is turned on and set to a higher MB treshold so that it can record for a long while.

Bill Klish

Makes sense. Can you clarify what the cache setting should be or should I wait for support to provide that answer? It was not clear in the post and we don't currently have it in the database.

I assume that a MB service restart will be required to pick up the change, although that isn't mentioned in the docs either.

Bill Klish

Ran a quick test with one user account that is not an admin, and has access to only one folder in the repository.

If I login as DOMAIN\user it is near instant.

If I login as LDAP\user it takes about 7 minutes.

This isn't making much sense. A packet sniffer and the MBP log shows the LDAP authentication was almost immediate. Does the MB server treat LDAP differently and do the folder permission checks differently?

msrinivas

Give the user at least list access to all top level folders and try it again.

Bill Klish

Interestingly, this user sees all top level folders when logged in as DOMAIN\user but only 3 of the top and the only 1 lower level folder that they have change access to.

Why would I see different lists for these?

msrinivas

To MB DOMAIN\bk99nd and LDAP\bk99nd are two different users.

Bill Klish

I realize that. I have checked and they have the same group memberships and permissions in the repositiry, yet they are returning 2 vastly different sets of folders when logging in.