Over the past 2 years, I've spent may days and nights trying to optimize our MOSS Enterprise Portals' performance (i.e. rendering time). In the end, the 3 biggest perf gains came from the following:
1. moving from x32 to x64 OS
2. moving the farm content dbs from a shared/busy SQL Backend Server to a dedicated/quieter one
3. moving from a 100 MB to 1 GB NIC connection on all of the Front end Servers
Although this did not solve all of our problems, it helped buy us time to perform a deeper investigation to identify what exactly was happening. For example, these were some of the problems found:
------
Problem: a high amount of SQL roundtrips from the Front end servers
Tool used to identify issue: SQL Profiler on the backend SQL profiler
Resolution: rewrite custom code to use more of the out of the box MOSS functionality versus extra db calls
------
Problem: caching wasn’t happening as expected on sone of the front end servers
Tool used to identify issue: Fiddler
Resolution: We turned on blob caching on the web.config file on server 1, but the changes didn’t replicate to server 2, server 3 and server 4 of the farm. We ended up manually updating the other web.config files
------
Problem: too many data connections, gifs, web parts, RSS feeds all on one page
Tool used to identify issue: Fiddler, Visual Studio 2005 - VSTT
Resolution: With fiddler, we were able to see how one page had multiple connections to other dbs, had over 10 gifs (some were actually being stored on a server on a different continent) and some RSS feeds. To fix this, we contacted the user and requested they reduce the amount of stuff put on a page.
-----
Problem: Front end Servers were under heavy load and there was a lot of blocking happening in SQL
Tool used to identify issue: Logparser
Resolution: Using Logparser, we were able to see that someone had an automated script running against the MOSS portal causing a type of denial of service attach. To fix this, we just contacted the user and let them know what they were doing to the farm.
-----
