Bill Baer /bɛːr/

Improvements in performance and scale in SharePoint Server 2016 IT Preview search now allow search to scale up to 500 million items, an increase of 250 million items SharePoint Server 2013 [http://technet.microsoft.com/en-us/library/cc262787.aspx#Search] based on 10 million items per index partition. In SharePoint Server 2013 and SharePoint Server 2016 IT Preview each index partition contains a subset of the whole search index. If the number of indexed items is high in relation to how much memory the server has, affects the query response time negatively.

Overview In SharePoint Server 2013 the List View Threshold specified the maximum number of list or library items that a database operation, such as a query, can process at the same time outside the daily time window set by the administrator during which queries are unrestricted. In SharePoint 2013 the List View Threshold is set to 5,000 or 20,000 for users and auditors respectively. Typically a users’ initial experience with List View Threshold is when it has been exceeded, the resultant error: The number of items in this list exceeds the list view threshold, which is 5000 items” as documented at https://support.

Make the most of the Developer Dashboard Monitoring Latency and SQL Server Round Trips Among the information provided through the Developer Dashboard is information about page latency and database queries surfaced under Execution Timeout in the user interface in the Web Server section. Using the information provided in this field you can determine whether or not a recently introduced feature or particular page is exceeding acceptable performance thresholds in your environment.

I read a great article on the SharePoint Team Blog during the morning commute providing insight into how sharepoint.microsoft.com was both evaluated and optimized for performance by Tony Tai – SharePoint Senior Product Manager, Microsoft Corporation and Ed Robinson – Chief Executive Officer, Aptimize Ltd. Read more…

This topic has frequented my Inbox over the past months, planning a My Site personal site deployment for 100,000+ users. In this post we’ll examine the issues and potential solutions. First it is important to understand that while a My Site personal site is a site collection in basic form, it’s instantiation via a browser request or managed code results in significantly greater overhead than a traditional collaboration-type site collection. The majority of overhead is presented through the numerous data building operations that occur both on the private and public pages associated with the template, private.

Performance recommendations and guidance is something I receive comment and question on quite frequently, typically in hallway conversation or in passing at conferences - so in the spirit of those occurrences I’ve decided to compile a quick list of SharePoint performance recommendations that can be conveyed verbally in five minutes or less. Governance Do limit the number of site collections/content database, I’m adamantly opposed to the “airline booking model” and much prefer what I like to refer to as the “accounting model” of database management, for example, if you know your maximum allowable site collection quota will be 5GB, and would like to keep your content databases at 100GB, logically you can host no more than 20 site collections per database and while this can result in a large number of content databases, you avoid site collection proliferation…with this model you should also take into account growth and set aside 5-10% to support schema changes, etc.

I’m pleased to announce the general availability of my most recent whitepaper, “Database Maintenance for Microsoft SharePoint Products and Technologies”. This whitepaper describes the recommended maintenance strategies for the databases that host content and configuration settings for SharePoint Products and Technologies. Read more…

A recent discussion on Garbage Collection management on 64-bit Web servers hosting Microsoft Office SharePoint Server 2007 led into a discussion on rendering performance, particularly steps to reduce overall rendering time at the client. While monitoring client rendering can be achieved to some degree through measuring TTLB - purely in ensuring pages are served in a timely manner (see ASP.NET Performance Monitoring, and When to Alert Administrators for monitoring recommendations), there are too many variables that can result in overall performance variations to include browser, hardware, machine state, etc.

The SharePoint Monitoring Toolkit enables administrators and IT Pros to manage SharePoint Products and Technologies deployments, both large and small, by introducing two (2) new management packs for System Center Operations Manager 2007. Both the Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0 management packs replace the existing management packs and have been engineered to leverage the rich features of System Center Operations Manager 2007. Improvements include: Additional rules to include performace rules Improved and new reports and views Backwards compatible dependencies have been removed Increased overall reliability Tuning and event supression reducing redundancy and more… To download the Solution Accelerator visit: http://go.

Master merge compiles all index data comprised of both in-memory and disk-based structures into one disk-based structure to prevent the degradation of the search service. SPS 2001 allowed administrators to manipulate the master merge schedule through HKEY_LOCAL_MACHINESoftwareMicrosoftSearch1.0CatalogNamesSharePointPortalServerworkspace_nameIndexer:ci:MidNightMasterMergeTimeDelta, but only to a limited degree of the specification of minutes past 12:00 A.M. that master merge should occur. Microsoft Office SharePoint Server 2007 does not provide an out of the box mechanism for manipulating the scheduling of the master merge process; however, options are available to script a scheduled master merge operation.

Ghosted and unghosted pages are references not new to Microsoft Office SharePoint Server 2007, but have received increased interest as a result of their impact on upgrading from previous versions and more recently, the ability to manage pages in an unghosted state. Introduction Ghosted is the preferred state of pages in a site collection, ghosted pages refer to site definition files cached in memory on the server at process startup of IIS.

TechReady5 concluded on Friday and I’m finally returning to work after several customer sessions that immediately followed and one question was shared between the two - what do you recommend or what are you using to monitor performance and how do you determine load and stress when architecting a SharePoint Products and Technologies infrastructure? The answer is, there are a variety of tools to stress test your Microsoft SharePoint Products and Technologies deployment; let’s cover some them:

One of the most common questions making its way to my Inbox as of recently is how to determine the required requests per second (RPS) to support a SharePoint Products and Technologies deployment. While many IT Pros opt to use the recommend values associated with RPS and Internet Information Services (IIS) the transactions are considerably different between a light-weight .NET application or common IIS Web site. To establish a general requirement for requests per second for a SharePoint Products and Technologies deployment you will need answers to the following questions:

This post is a continuation on previous SharePoint Portal Server 2003 performace recommendations and details basic steps to improve the overall full-text search queries for large database tables. The steps detailed are most applicable to enterprise deployments and/or large databases with a large number of unique full-text index words. The steps detailed below should be applied to each back-end SQL server(s). This problem occurs frequently if the total size of all the catalog files exceeds 256 megabytes (MB).

I recently came across an issue with a customer that uses large files in WSS, notably, .CAD files; as a result these files were either - one, not indexed or two, indexing did not gather the required information from the file to provide useful search criteria. To remidy the issue MaxDownloadSize was increased to 64MB while leaving the MaxGrowFactor at 4, this will essentially permit the index filter to produce up to 256MB (64 x 4) of text from a given file, the default setting in SPS is 16MB MaxDownloadSize and 4 MaxGrowFactor, limiting the index filter to 64MB max.