Sunday, March 20, 2005
We haven't discovered what causes the delay yet, but what we have discovered is that the worker process memory usage gradually grows to the maximum 800 MB. This is when the response-time issue start to happen. This usually takes place during the day when Portal usage is expected to be high.
So far we've been able to create a temporary workaround by adding a third web frontend to the Sharepoint Portal Server farm. The cause of the memory fillup followed by the large response times is as yet unknown.
Moral to this (continuing) story:
If there are no obvious signs (CPU/Memory/IO) as to why your Portal is reacting so slow to user requests and you want to find the cause, there are three pieces of the puzzle you want to have to be able to do some serious troubleshooting:
- User statistics. Think IIS logging.
Why? You want to be able to compare usage to any other statistics gathered from your systems.
- System Statistics. This can be anything from ASP.NET counters to network usage to SQL tracing. Basically, how is your farm/infrastructure behaving?
- Webpart architecture. This is especially important if there has been some serious webppart programming going on in your Portal environment. Even more so if external datasources are accessed. Think web services, databases etc.
When webparts are introduced in your Portal System they will alter the behaviour of your Portal farm. Don't be caught off-guard.
Saturday, March 12, 2005
Daniel, thank you for our pleasant dinner and for the opportunity of working with you for those two days, exchanging knowledge, ideas, theories and just plain having fun. I'm looking forward to see you fulfill your end of the bargain, including putting the photo online.
Subscribe to Posts [Atom]