of how the farm is intended to be used often exposes perceived weaknesses in the original
design. Add to that the changing requirements placed on the system by the user base, and
you have a situation that is ripe with tuning potential.
The tuning and optimization portion of your project is the chance for you to tweak the
underlying configuration of the farm, enabling you to both enhance performance metrics and
avoid any limitations placed on the system by its original design.
Tuning and optimizing a SharePoint environment require to:
- Plan and configure SQL optimization.
- Execute database maintenance rules.
- Plan for capacity software boundaries.
- Estimate storage requirements.
- Plan and configure caching.
- Tune network performance.
Summary:
- Network Attached Storage (NAS) is supported only for use with Remote BLOB Storage (RBS).
- As a rule, performance priority should be given first to TempDB files and transaction logs, then database transaction log files, then search databases, and finally database data files.
- The model database can be used to configure the initial size of a newly created SharePoint content database, but not its autogrowth rate.
- Splitting a SharePoint content database into multiple database files is a supported (but advanced) way to enhance its performance level.
- A split-content database cannot be backed up or restored from within SharePoint Central Administration, but must instead be backed up from SSMS.
- Altering values for the ASP.NET output cache, BLOB cache, and object cache require additional memory and disk resources on the web tier servers and can result in a pronounced performance gain. Additional memory and disk resources are required on the web tier servers, however.
- The page output cache can be enabled and configured at the web application, site collection, site, or page layout levels.
- Separating client and intrafarm communications can result in a significant networking performance gain within your SharePoint farm.
