Home
TeamSite
Slow performance accessing tree structure
System
When we logon to the web client or the native client the container structure takes 4+ minutes to open. What could cause this to happen. There are hundrens of containers under the root. However we have changed the container value in SQL MBSettings from 100000 to 150000 and still no performance gain. Could someone please advise.
MB 4.0
Find more posts tagged with
Comments
lyman
The first step is to see what performance looks like when you log in as a user that is in the MbAdmin group. This will help narrow down the cause as members of this group do not go through the normal security channels.
Also try to see if there is a signficant difference between the performance of the Windows Native Client and the web client.
Cheers,
Lyman Hurd
Migrateduser
Lyman,
The issue presents itself as an admin user. It takes the same amount of time in both instances. I clocked both the web client and the native client. Let me clear this up some. The initial containers open the problem surfaces when we open the container that has the majority of our customers folders.
Migrateduser
How many assets and immediate subfolders are in this container? How many columns are you displaying? The more columns you display, the slower the performance.
You state you're on version 4.0. I'm assuming then that you've had MediaBin for at least a year or two. Has performance suddenly degraded? If so, what's changed? 4.5.3 has some improvements to the MediaBin repository that improve performance. Also, a third party vendor, Rapid Soft, sells a paging control add-on for the 4.5.3 web client that is recommended if you have more than several hundred assets in a folder (this number depends on the memory available and speed of your hardware).
You should try increasing the size of the cache maintained by the web client and the native Windows client. Information required to render assets, containers, metadata, etc. are cached and updated dynamically by the client to improve performance. Remember, because it is a cache, you would still incur slow performance the first time you access this folder. Subsequent visits should be faster for all users. However, eventually the cache will fill and will purge items to make room for newly accessed items to fit. Therefore, from time to time, you would notice slower performance when revisiting a folder. The cache persists in the web server approximately 20 minutes after the LAST user has logged out. It has been observed that Microsoft's worker process unloads dlls after 20 minutes if no ASP session is active.
Try increasing these values in the registry of your web server. This assumes you have at least 2GByte RAM on your web server.
Attached is an exported registry key that you can use for testing. .REG files are readable so you could take a look at some of these values and apply them manually or simply import the key. You should export your existing key before making any changes so you can recover it. You will need to remove the .txt extension.
Migrateduser
Lyman,
I will make these changes. Can you tell me the purpose of each key. That way I can explain to the higher ups exactly what they represent and why we made the changes.
Thank you.
We do have alot of folders. The container value is 21286 and the containertree value is 93450. We would love to move to the latest version of MB but it is not possible because of our OFM. Unless we have you guys completely re-design the OFM (which I do not think is an option). If you may recall you worked with Eric Kibisingo in the past. I am with the US Senate Photo Studio. Thanks again for your help.
Migrateduser
You may want to verify you haven't already adjusted these values to something higher already.
These are the values in the reg key that apply to the cache. The others in that key apply to client side logging which was not implemented in 4.0, so they will have no effect. Note the values are in hexidecimal. That is how they are exported from the registry.
"ContainerCacheMaxSize"=dword:000003e8 - Max number of container objects cached on client. There is a one to one relationship between a container object and a container in the MediaBin repository.
"ChildImageCacheMaxSize"=dword:000003e8 - Max number of child image identifier sets that can be cached on client. Normally value is same as ContainerCacheMaxSize.
"ImageCacheMaxSize"=dword:00002710 - Max number of asset objects cached on client. There is a one to one relationship between an image object and an asset in the MediaBin repository. This cache contains the latest version of the asset.
"ImageRevisionCacheMaxSize"=dword:00001388 - Max number of asset objects that represent versions earlier than the latest, that can be cached on client.
"ImageRevisionHistoryCacheMaxSize"=dword:00001388 - Max number of descriptor maps of asset history that can be cached on client. Each map contains asset revision number/asset revision descriptor pairs.
"MetaDataCatalogCacheMaxSize"=dword:000001f4 - Max number of metadata definitions that can be cached on client.
"MetaDataAccessFilterCacheMaxSize"=dword:000003e8 - Max number of metadata lists per logged-on user that can be cached on client. Each list contains an asset identifier/metadata identifier pair and determines what metadata, from the MetaDataCatalogCache, that user has permissions to access.
"MetaDataFilterCacheMaxSize"=dword:0000c350 - Max number of sets of metadata identifiers assigned to an asset that can be cached on client. This includes asset revisions as well as the latest revision.
"MetaDataValueCacheMaxSize"=dword:000493e0 - Max number of values for metadata assigned to assets that can be cached on client. For example, two assets may have the same metadata assigned with different values for each, resulting in two entries in this cache.
"JobCacheMaxSize"=dword:000001f4 - Max number of job objects cached on client. A job object represents an insertion or retrieval job.
sarahs
Thank you for posting this -- recently we encountered a rapid degradation of performance of the web client's ability to render content in that lower-left "container" pane; I tried making the regestry changes on the web server and then restarting the IIS service, but I noticed no application performance improvement.
Are there any other suggestions? What indexes should exist for the container table? Does media bin have any 'index audit' script that I could run to validate that the DB doesn't have a problem?
I've taken a look at the data in the tables and what I have discovered is that rows are created in containers and assetref every time a container is created; when a container is deleted -- no rows are deleted from either table. I have run the "cleanup" job but it doesn't appear to clean up these dangling records in the database.
By the way, I implemented the registry fix and found ZERO performance increase. I then discovered the data issue, deleted some container records and their references and then found that the time to see the containers in the web client went from 30 seconds to 4 seconds.
msrinivas
I would recommend you opening a support case so that we have a case history. You will be able to get better assistance for performance issues etc., via support than here. There is no silver bullet for this.
