Hi Zack,

I'm sort of glad to hear I'm not the only one having this problem, but unfortuantely I'm still not closer to the solution.

The only pointers i can give is that we first did a test upgrade to 4.5.1 of the whole intranet to a Quality Assurance server, without any problems.

There were no core adjustments made, and a very limited amount of custom scripts was run on the DB for upgrading (change over from Speerio NukeHTML to FCKeditor for ASP.NET 2.0 compatibility)

The site is reasonably large with around 6GB of storage used, and over 1200 Tabs.Should i get any further I'll post here as soon as possible as well.

Leon

Hi all,

I have been looking into this a bunch, and was able to narrow it down to the following call stack, with the problem method a the bottom.

• AddTab
• UpdatePortalTabOrder
• UpdateTabOrder
• GenerateTabPath
• GetTab
• GetTabsByPortal

However if GetTabsByPortal was the problem, why is the function not slow the other 99% of the time?  As I looked into this, I realized that the cacheing of the portal's tabs was never sticking.  It would create a new cache entry, just to have it get wiped out before the next call to GetTabsByPortal.  So, backing up through the code, I found that the cache was being cleared in the UpdateTabOrder function. 

I removed the ClearCache line from the UpdateTabOrder function, and everything appears to be working fine. 

Can anybody tell if this solution will cause any problems?

Thanks,

Zack

In looking at the code and examining the various code paths to the UpdateTabOrder method, it appears that the ClearCache() call is not necessary because the calling method already includes a call to ClearCache(). In the case of UpdatePortalTabOrder, UpdateTabOrder is being called within a loop which iterates through the entire tab collection - so caching is clearly a requirement here for optimal performance. I will do some mor investigation but I definitely appreciate your observations.