This is a great article on improving SharePoint 2007 performance.
https://technet.microsoft.com/en-us/library/cc964305.aspx
In an ideal world, you would account for SharePoint performance optimization in the planning and design stages with adequately sized and architected servers, support teams, and underlying infrastructure. But in the real world, you’ll have trouble predicting user adoption rates. Your budget may be cut or staff downsized. You may inherit a poorly performing SharePoint environment. Even if your infrastructure at first meets performance expectations, growing numbers of documents, groups, lists, and sites may increase page load times and decrease satisfaction.
One of the biggest challenges you’ll face in your efforts to optimize SharePoint performance will be navigating through the many configuration options that the underlying IIS, .NET, and SQL Server technologies provide during the planning and design stages, as well as in hands-on operation. The sheer number of options is daunting, not to mention trying to figure out which option is best suited to your needs. For example, SQL Server houses the vast majority of SharePoint configuration data and content, yet the search, content, configuration, and temp databases have very different read/write patterns that require appropriate disk throughput and RAM. To complicate the picture, you also can use caching in IIS or offload indexing to a front-end server to help increase disk throughput.
A second challenge revolves around determining the root causes of performance issues. SharePoint relies not only on the core SQL, IIS, and .NET components, but also on interdependencies such as Active Directory, the network, SharePoint architecture, and physical server hardware. This means a performance issue may have more than one root cause, and similarly require making multiple changes for problem resolution. Operational jobs, backup routines, and third-party tools add more possible root causes to performance issues.
In this column, I present an overview of key SharePoint architecture components, describe how they can lead to common performance issues, and discuss how to resolve and troubleshoot problems.
Performance Criteria
Before I go into the relationships between IIS and SQL Server design, configuration options, and impact on performance, let’s establish the target of performance optimization. Put simply, it is improved user and administrator experience in terms of key indicators such as page load times, search, and crawling. If pages don’t load fast for your users, then your effort to optimize performance by eliminating 10 round trips to the SQL Server databases doesn’t matter.
When considering how quickly a page appears for a user, be sure to think about initial and subsequent load times. You might have instances in which users load a single page once but, generally, SharePoint use involves people accessing many sites and document libraries repeatedly. That’s why focusing on opportunities that yield decreased load times for all page requests is so important. Keep in mind that because of browser caching, the first time a page loads the render time will be different than it is for subsequent page loads.
Performance Interdependencies
In my May 2008 column, “Building Your SharePoint Infrastructure“, I covered the SharePoint architecture and explained at a basic level how IIS, SQL Server, and .NET work together to render requested pages. Now let’s consider how to configure the core technologies to meet your performance needs. Figure 1 shows the key components that relate to optimization options.
Figure 1 SharePoint Architecture Components Affecting Performance
<Snip>
Read the rest @> Inside SharePoint: Improving SharePoint Performance
