Common issues and resolutions:
http://technet.microsoft.com/en-us/magazine/2009.08.insidesharepoint.aspx
performance tips and tuning in configs:
http://sharepointbergen.blogspot.com/2007/07/sharepoint-2007-performance-and-tuning.html
Different caching parameters:
Enable the BlobCache in web.config to create a disk cache for all pictures, style sheets and scripts that are used => Reduced database traffic.
Consider reducing the number of application pools used to relase more memory on the server(s). Each application pool is assigned a unique worker process which again loads the runtime => More memory for caching the "real stuff" :-)
Set the correct Caching profile on each web site - from the Admin page => Quicker page loads.
Web parts and customizations
Write your web parts and custom controls and pages such that the do as little data processing as possible before the user makes an action. => Reduces the time to load a the page that are using your web part/component.
Site structure
Depth of the web site hierarchy => Content by Query and other querys will run quicker
And.....
Resolving Performance Issues
Regardless of the framework and methodology you use in trying to understand your SharePoint performance issues, isolate their root causes, and resolve the problems, you need baseline data that reflects acceptable performance against which you compare data that reflects poor performance. You can obtain a baseline set of performance data either right after your initial deployment, during periods of acceptable performance, or from best-practice recommendations. If you have no basis for comparison, then you can use Microsoft published performance recommendations for various measurements, available at technet.micro-soft.com/en-us/library/cc262787.aspx.
As I already mentioned, the most common performance issues happen as a result of interrelated components. This can be troublesome because the underlying indicators are often the same. For example, one common indicator of a performance issue is a spike in resource utilization, such as RAM, CPU, or disk I/O. To resolve the performance issue, you need to look at all available data, understand the sequence of events leading to the issue, and correlate events to determine the underlying root cause. Figure 2 shows common performance issues, possible root causes, and resolution options.
Figure 2 Issue, Cause and Resolution Summary
Issue Possible Root Causes Possible Resolutions Additional Resources
High disk I/O activity on SQL Server Large list operations, timer jobs, SQL maintenance tasks, backup, indexing, inadequate RAM, high I/O databases such as temp tlog, search, and content, placed on same disk or slow disks. Separate temp and search databases in multiple files across high I/O disk volumes, increase RAM, use dedicated disks for transaction logs, defragment, and re-index databases weekly. technet.microsoft.com/en-us/library/cc678870.aspx
msdn.microsoft.com/en-us/library/ms175527.aspx
technet.microsoft.com/en-us/library/cc263261.aspx
technet.microsoft.com/en-us/library/cc262067(TechNet.10).aspx
SQL blocking/locking NIC configuration, large list operations, indexing/crawling jobs. Do not use SharePoint Team Services Administration (STSADM). Use SQL backup, DPM, Litespeed, or SQL 2008 with compression, ensure fill factor is set to 70% on content databases, enforce 100GB growth limit. technet.microsoft.com/en-us/library/cc901593.aspx
go.microsoft.com/fwlink/?LinkID=105623&clcid=0x409
support.microsoft.com/kb/271509
support.microsoft.com/kb/298475
Overall slow page loads Compression not enabled. Caching not enabled or not configured. Large pages. Redundant SQL trips, underlying network issues. Enable caching and compression, check page load times, and examine SQL queries and round trips, check NIC for Broadcom 5708 Chimney issues. technet.microsoft.com/en-us/library/cc298550.aspx
support.microsoft.com/kb/942861
Long time to load full page Improper SharePoint object handling in custom code, slow links, SQL blocking, timer jobs, Web part caching not enabled. Resolve back-end bandwidth and response issues, dispose of objects properly, use 64-bit hardware or configure memory pool limits, delay downloading core.js. code.msdn.microsoft.com/SPDisposeCheck
technet.microsoft.com/en-us/library/cc298550.aspx
technet.microsoft.com/en-us/library/cc678870.aspx
technet.microsoft.com/en-us/library/cc298466.aspx
Poor list performance Large lists >2,000–3,000 items in a level. No indexing on lists. Underlying SQL Server issues. Too many columns. Index on one or more columns, ensure SQL Server performance, keep fewer than 2,000–3,000 items in a level. go.microsoft.com/fwlink/?LinkID=105580&clcid=0x409
Long crawl and index times or indexing causing sluggishness Large data volumes require long index times, no dedicated index target. Block with robots.txt, offload crawling/indexing to dedicated front-end server. technet.microsoft.com/en-us/library/cc261810.aspx
LDAP operations (such as authentication and user operations) causing usage spikes Low bandwidth, remote domain controller, large profile imports. Increase bandwidth, use Kerberos, optimize profile importing. support.microsoft.com/kb/827754
Backup taking too long Using STSADM, other SQL conditions such as blocking. Use Microsoft Data Protection Manager (DPM) or SQL 2008 with compression. technet.microsoft.com/en-us/library/cc901593.aspx
IIS out of memory conditions Application pool and worker process recycling, improper object handling, not enough RAM, poor load balancing architecture. Use IIS overlapped recycling, use 64-bit hardware. msdn.microsoft.com/en-us/library/aa720391(VS.71).aspx
technet.microsoft.com/en-us/library/cc737679.aspx
As you narrow down possible causes for performance issues, keep in mind general operations best practices, such as the ones documented in the IT Showcase white paper, "SharePoint Performance Optimization." Applying the latest patches, service packs, and updates for SQL Server, IIS, SharePoint, and Windows Server is especially important. Microsoft has fixed many previous performance issues, such as tempdb allocation contention (see Concurrency enhancements for the tempdb database) and TokenAndPermUserStore cache (see Queries take a longer time to finish running when the size of the TokenAndPermUserStore cache grows in SQL Server 2005).
Troubleshooting Tools
You can rely on a diverse range of tools for digging down to the specifics of a SharePoint performance issue and gathering evidence that would help you make a diagnosis, determine the root causes, and resolve the problem.
The following tools are especially helpful in pinpointing causes of performance issues:
Fiddler PowerToy and neXpert add-on Used together, these tools provide a solid starting point for page load analysis. They allow you to review caching, compression, and overall HTTP performance. You can get more information about these tools at Fiddler PowerToy - Part 2: HTTP Performance and Microsoft neXpert Performance Analysis Plugin.
WireShark When you need to look into network issues, use WireShark. It works with many media, and you can capture packets from recreated TCP/IP conversations when you recreate issues. For more information, see wireshark.org.
Visual RoundTrip Analyzer (VRTA) You can use VRTA to examine the round-trip performance from request to response. VRTA examines the communications protocol, identifying the causes of excessive round trips, and recommending solutions. You can download it from Microsoft downloads, Visual Round Trip Analyzer.
SQL Profiler You can use this useful tool, installed with SQL Server, for monitoring an instance of SQL Server Database Engine or SQL Server Analysis Services. It enables you to discover issues with queries, deadlocks, timeouts, recompilations, and general errors and exceptions.
SQLDiag This tool, also installed with SQL Server, collects valuable information about the configuration of the computer running SQL Server, the operating system, and the information that is reported to the SQL Server error logs.
SQL Query Analyzer This is a low-level debug tool for analyzing query performance issues. It also is part of the SQL Server toolset.
SPtraceview This is one of my favorite tools because it provides a view of performance issues in real time. It's useful for monitoring diagnostic tracing when working with custom Web parts. For more information, see SPTraceView – Lightweight Tool for Monitoring the SharePoint Diagnostic Logging in Real-Time.
WSSDW.exe This is a performance-testing tool that populates data for testing deployments of Office SharePoint Server 2007. See Tools for performance and capacity planning (Office SharePoint Server) and SharePoint 2007 Test Data Population Tool for more information.
Custom tool for client-based URL ping This is one of the most useful tools because it enables the comparison of statistics before and after implementing configuration changes to the environment. See the appendix on the SharePoint Performance Optimization page.
Constant Monitoring
SharePoint performance tuning, like most things SharePoint, is complex. You need to understand the object model, details about the SharePoint architecture, and the interactions between IIS/.NET and SQL Server. You also need to know database administration and troubleshooting best practices. The good news is that if you lack this understanding, you can still do well at optimizing your SharePoint infrastructure by following established best practices, recommendations, and knowledge, and addressing the common issues pointed out here.
