Site and solution planning. Best practices for search in SharePoint Server 2010. Applies to: SharePoint Server 2010 In this article: 1. Plan the deployment2. Start with a well-configured infrastructure3. 1. 2. 3. We recommend that you add users to Windows security groups or role claims instead of adding users to SharePoint groups for the following reasons: Because changes to Windows security groups do not directly affect the access control entries (ACEs) on SharePoint sites, you do not have to perform a new crawl when user accounts within those Windows security groups are changed.During the indexing process, the system stores the ACE of each user who was added to a SharePoint group instead of the ACE of the SharePoint group itself. 4. Important If you are mirroring the computers that run SQL Server, turn mirroring off before you defragment the search database and turn it back on after defragmentation is completed. 5. 6. 7. When you use certain file-level antivirus software programs in SharePoint Server 2010, you should exclude certain folders from being scanned.
Best practices for operational excellence. Applies to: SharePoint Server 2010, Excel Services Microsoft SharePoint Server 2010 is used for a broad set of applications and solutions, either stand-alone or in concert with other systems. To achieve this flexibility, the platform supports lots of possible architectures and configurations. Some parts of the system are well-known, but we still see variances to these parts. This article focuses on the top configuration best practices that you should consider, such as front-end Web server configuration, database configuration, servicing, and patching. 1. Use lots of memory, and fast network adapters To get the performance you want from an environment, make sure that you use lots of memory on the Web and application servers. Network speed is also important for performance of the environment. Use gigabit network adapters for all server roles.For front-end Web servers and application servers, use dual network adapters in production environments. 2. 3. 4.
Note 5. 6. 7. 8. 9. 10. Acknowledgments. Best practices for capacity management. Using the Developer Dashboard. Published: May 2010 In the past, the only way to debug performance problems caused by the extra overhead of these instances in code would be to attach a debugger to the code and monitor SQL Server Profiler traces. With the Developer Dashboard, a developer can identify this type of problem, either programmatically by using the object model or visually by looking at page output.
Although performance issues and resource usage information is available in the Unified Logging Service (ULS) logs, interpreting the raw data can be very time consuming. With the Developer Dashboard, all the related information is correlated, which makes identifying these types of issues much easier. Developer Dashboard contains an extensible mechanism for measuring various performance counters at various scopes. Per-Thread Counters These counters measure values for the current request or timer job: The preceding data is output to two locations at the end of every request or timer job: Using STSADM.
Server farms and topologies. Sign in TechNet Library Design server farms and topologies (SharePoint Server 2010) SharePoint 2010 Other Versions Published: February 3, 2011 This section contains resources to help you learn about and plan topologies for Microsoft SharePoint Server 2010. In this section: Did you find this helpful? Tell us more... (1500 characters remaining) Thank you for your feedback Show: © 2014 Microsoft Manage Your Profile Site Feedback © 2014 Microsoft. Checklist for Testing SharePoint Web Parts. Lana Fly Susan Harney Microsoft Corporation November 2004 Applies to: Microsoft Windows SharePoint Services Microsoft Office SharePoint Portal Server 2003 Summary: Use this checklist to assist with the deployment and maintenance of Microsoft SharePoint Products and Technologies Web Parts. (11 printed pages) Contents Introduction Task Checklist for Testing Web PartsConclusionAdditional Resources Introduction If you install and maintain the Web Parts for your Microsoft Office SharePoint Portal Server portal site or Microsoft Windows SharePoint Services team site, you should help ensure that the Web Parts are secure, well-written, and can integrate appropriately with other components on the Web Part Page.
By understanding the tasks we describe in this article, you can determine whether a Web Part meets these requirements, and help enhance the success of your Web Part deployment and maintenance. Task Checklist for Testing Web Parts Task Checklist To test Create a new Web Part Page. Open FrontPage. Software boundaries and limits. Applies to: SharePoint Server 2013 Standard, SharePoint Server 2013 Enterprise, SharePoint Foundation 2013, Project Server 2013 Topic Last Modified: 2014-04-02 Summary:Learn about the tested performance and capacity limits of SharePoint Server 2013 and how limits relate to acceptable performance. This article describes software boundaries and limits of SharePoint Server 2013. These include the following: Boundaries: Static limits that cannot be exceeded by design Thresholds: Configurable limits that can be exceeded to accommodate specific requirements Supported limits: Configurable limits that have been set by default to a tested value In this article: This article contains information to help you understand the tested performance and capacity limits of SharePoint Server 2013, and offers guidelines for how limits relate to acceptable performance.
Boundaries are absolute limits that cannot be exceeded by design. An example of a supported limit is the number of site collections per farm. Performance and capacity test results and recommendations. Updated: July 23, 2013 Summary: Learn about performance characteristics of features in SharePoint Server 2013. Applies to: SharePoint Foundation 2013 | SharePoint Server 2013 Enterprise | SharePoint Server 2013 Standard The following articles describe the tested performance and capacity characteristics and effect of specific scenarios and feature sets in SharePoint Server 2013. These articles include information about the characteristics of the scenario or feature and how it was tested by Microsoft, including: You can use the information in these articles to understand the performance and capacity characteristics of a specific scenario or feature under both normal and peak loads, and how performance trends for a scenario or feature change when farm servers are scaled out or hardware resources are added to existing servers.
Storage and SQL Server capacity planning and configuration. Published: August 27, 2013 Summary: Learn how to plan and configure the storage and database tier for SQL Server in SharePoint 2013. Applies to: SharePoint Server 2013 The capacity planning information that we provide contains guidelines to help you plan and configure the storage and SQL Server database tier in a SharePoint Server 2013 environment. This information is based on testing performed at Microsoft on live properties.
Because SharePoint Server often runs in environments in which databases are managed by separate SQL Server database administrators, this document is intended for joint use by SharePoint Server farm implementers and SQL Server database administrators. Several SharePoint Server 2013 architectural factors influence storage design. Before you start to plan storage, you should understand the databases that SharePoint Server 2013 can use. In this section: Databases used by SharePoint 2013 Understand SQL Server and IOPS Estimate core storage and IOPS needs Choose disk types.
Virtualization planning. Global deployment of multiple farms. Load Testing Kit. Applies to: SharePoint Server 2010, SharePoint Foundation 2010 This article provides a basic overview of and how-to steps for the Load Testing Kit (LTK) of the Microsoft SharePoint 2010 Administration Toolkit. Overview The Load Testing Kit (LTK) lets an administrator simulate a synthetic load test against a Microsoft SharePoint Server 2010 farm.
The goal of the tool is to assist an administrator to certify that an existing Microsoft Office SharePoint Server 2007 topology running on specific hardware can sustain an upgrade to a Microsoft SharePoint Server 2010 farm, with the same load. The Load Testing Kit is a command-line tool that will use information from a Office SharePoint Server 2007 production farm as a baseline. Collect logs.Prepare data for analysis.Use the project file to generate a synthetic load. To install the Load Testing Kit, you must be a local administrator on the any x64-based computer. Collect logs Note Prepare data for analysis Ltk.exe syntax ** -output <output directory>**
Performance and capacity technical case studies. Published: May 12, 2010 This section contains technical case studies that describe specific deployments of Microsoft SharePoint Server 2010. Compare the scenarios in these documents to your planned workload and usage characteristics. If your planned design is similar, you can use the documented deployment as a starting point for your own installation. These articles include information about environments, such as: Environment specifications, such as hardware, farm topology, and configuration The workload used for data generation, including the number and class of users, and farm usage characteristics Farm dataset, including database contents, Search indexes, and external data sources Health and performance data specific to the environment Performance data and recommendations for how to determine the hardware, topology, and configuration you need to deploy a similar environment, and how to optimize your environment for appropriate capacity and performance characteristics.
Monitoring and maintaining SharePoint Server 2010. Published: October 23, 2012 Summary: Learn about how to monitor and maintain SharePoint Server 2013. Applies to: SharePoint Server 2013 Standard | SharePoint Server 2013 Enterprise This article discusses monitoring and performance counters for SharePoint Server 2013 farms. To maintain SharePoint Server 2013 system performance, you must monitor your server to identify potential bottlenecks. Before you can monitor effectively, you must understand the key indicators that will tell you if a specific part of your farm requires attention, and know how to interpret these indicators. If you find that your farm is operating outside the targets you have defined, you can adjust your farm by adding or removing hardware resources, changing your topology, or changing how data is stored. The information in this section is intended to help administrators manually configure performance counters and other settings.
In this article: Performance counters System counters SQL Server counters. SharePoint 2010 Administration Toolkit. Published: July 15, 2010 This article provides information for farm administrators about the April 2011 release of the SharePoint Administration Toolkit version 2.0, which includes the following features: The Load Testing Kit, which generates a Visual Studio Team System 2008 (VSTS) load test based on Microsoft Office SharePoint Server 2007 IIS logs. The VSTS load test can be used to generate synthetic load against Microsoft SharePoint Server 2010 as part of a capacity planning exercise or a pre-upgrade stress test. The Security Configuration Wizard (SCW) manifest, which add roles for SharePoint 2010 Products to Windows Server 2008 with Service Pack 2 or to Windows Server 2008 R2.
The User Profile Replication Engine, which provides a shared services administrator the ability to replicate user profiles and social data between shared services providers (SSP) in Office SharePoint Server 2007 and User Profile service applications in SharePoint Server 2010. In this section: SharePoint Diagnostic Studio 2010 (SPDiag 3.0) SPDiag provides various reports that present data from logs, SharePoint databases, and performance counters. Reports collect data from the SharePoint farm and display aggregated information that is focused on specific aspects of farm performance. You can also begin your investigation by directly opening a report from the Reports pane displayed at the bottom of the guide window. These reports are described in the following paragraphs.
The Base report group contains several reports that display information about key general performance indicators. HTTP Requests This report displays all HTTP requests across the farm. When you select a row from the top report, the full trace from the request is fetched and displayed in the bottom pane. Right-click any cell to add a filter with the column name and value of your selection. Click any column header to sort by that column. Once you have customized the filter list, you can save the report so you do not have to generate it again. Windows Events Crashes. Designing large lists and maximizing list performance. Before you implement a large list, consider the business case and requirements.
Requirements such as service level agreement (SLA), time for backup and restore, size of content, amount of content (number of items), and access times are all important to consider. Depending on the size and demand of the application, you must make important choices at multiple levels, including hardware, content storage, and SharePoint Server 2010 information architecture. A large application that has millions of items and hundreds of concurrent users might require stand-alone hardware for the specific project, although a document repository with tens of concurrent users and tens of thousands of documents can work well with existing shared hardware and a single document library in an existing site. After you plan the design and implementation for a large list, the next step is to design and build a prototype.
Single list, multiple lists, or multiple site collections Summary of list recommendations Metadata. Plan for availability. Capacity management and sizing for SharePoint Server 2010. Large scale document repository performance and capacity. Best practices for people and profiles. Best practices for backup and recovery. Best practices for SQL Server 2008 in a SharePoint Server 2010 farm.
Best practices for content deployment. Best practices for publishing sites. Best practices for team collaboration sites. Best practices for My Sites. Best practices for virtualization. Best practices for extranet environments. Best practices.