Key SharePoint Limits
Microsoft publishes a long list of soft and hard boundaries and limits within SharePoint. These have not changed significantly between 2010 and 2013. The definitive list can be found at: https://technet.microsoft.com/en-us/library/cc262787.aspx
An example of a hard boundary limit is the 2GB limit on file size. This limit is based on Operating System and SQL Server limits, and involves no trade-off options. However it is not advisable to allow for 2GB uploads, without first considering the options and tradeoffs involved, as well as end-user performance, and configuration settings such as BlobCache that can alleviate some of the delays associated with huge files.
An example of a soft limit is the List View threshold of 5,000 that prevents any list from trying to display more than 5,000 items. Even trying to display 5,001 will return an error. This setting is easily changed, but the impact can be significant, as the underlying SQL Server changes from row locking and imposes table locking on edits of over 5,000 items. This is an example of trading off performance and scalability with any usability benefits of increasing this setting. There are situations where it may make sense, such as a farm with a disproportionately low number of concurrent users, leading to a good trade-off of table locking with a low likelihood of another user being concurrently impacted. However, for a larger number of concurrent users, you definitely do not want to increase this threshold, without causing likely and noticeable performance degradation.
While there are a large number of limits, the ones that are most likely to guide your design are the two listed above, plus Security Scopes and Content Database size.
Security Scopes in a Library
Each time an object (web, library, folder or item) gets unique security permissions, that is termed a “Security Scope”. If 100 documents are assigned unique permissions, but have the same three people as contributors, this still counts as 100 Security Scopes. If they are each assigned to 200 Contributors, that still is only 100 Security Scopes. A rule of thumb is once you reach 1,000 unique Security Scopes, performance degrades 20%. Increase the number further, and performance nosedives. If you are going to have large libraries, it is best to have few or no unique Security Scopes. This is purely a performance impact, and the result is noticeable.
Content Database Size
This has the most direct impact on your DR strategy. The limits of your hardware (bounded by laws of physics) determine the speed of your backups and restores. The larger the Content Database, the longer your backup and recovery. A prime example is restoring a single Content Database. The scenario is a user “stomps” on a document, replacing it completely, using Explorer Mode. You’ve got to restore from a backup, you start the restore and get ready to do an unattached database extract, and are waiting for the restore to complete. However the large Content Database of 200GB or more requires the better part of a day to restore, or worse, you have insufficient spare disk space for the restore.
URL Length
Aside from the published limits, there’s a crucial limit that is not listed in the SharePoint Boundaries and Limits site, which is the maximum length of a URL of 255. That might sound like a large URL, but once you use a FQDN (Fully Qualified Domain Name) for your Web Application, a Managed Path, Sites and SubSites, Libraries and Nested Folders, enterprising users will utilize longer file names than you’d imagine, sprinkling them with characters not easily represented in a URL (such as blanks), causing them to be expanded to %20 (hex of ASCII 32, which is a blank). This limitation is insidious. Your design could appear to work fine…until users encounter seemingly random problems, where only some files have issues. Renaming files and folders tersely can buy some relief, replacing blanks with underscores, or getting users to use CamelCase is a tough sell to end users used to naming files as they want.
Impact of Design Decisions
Design decisions can be made implicitly that have a great impact on scalability, performance and DR. Let’s summarize these key decisions:
- Web Applications
The fewer the better. Aside from the untouchable Central Admin Web Application, and separate MySites, try to limit your Web Applications. Each Web Application carries not only its own configuration, but also a whoel raft of dedicated Timer Jobs firing multiple jobs every second, and additional IIS load, even if you share an Application Pool among multiple Web Applications. - Managed Paths
These are defined at the Web Application level, and provide the structure for additional Site Collections. - Host Named Site Collections
Aside from perhaps Search, this is the largest infrastructure change in SharePoint 2013. It’s geared to allow for cloud based multi-tenancy, and scalability beyond what can be done with the relatively structured Managed Paths. Best is to select one Web Application, and use that for all Host Named Site Collections. - Number of Site Collections
Some users feel comfortable within the confines of a single site collection. There are certainly conveniences within a site collection, including shared security groups, shared content types, and an immediate navigable hierarchy. Going with monolithic Site Collections limits your ability to scale across Content Databases, as a Site Collection can only ever exist within one Content Database. Once a Site Collection has grown too large, splitting it can be fraught with challenges. A large Content Database takes proportionately longer to backup, and more importantly, to recover. - Number of Sites
A more diverse set of Sites (SPWeb objects, not to be confused with Site Collections) and their hierarchy requires thoughtful design to echo how users typically navigate SharePoint. A greater number of sites is recommended, which in turn should allow for scalability. - Number of Libraries
Huge libraries suffer a proportionate impact to performance, and expose the possibility of errors if a View returns a result set larger than the List View Threshold (default and recommended setting of 5,000). It is better to guide users to replace a desired set of top level folders instead with libraries.
Going with a more diverse yet coherent and logical structure of Site Collections, Sites, and Libraries will allow for the scalability your farm needs to satisfy daily user needs, as well as growth objectives.
A good approach when working with users is to play down the name (site collection, site, library and folder) and focus instead on the hierarchy, which users understand. You can always tune navigation to give them an optimal experience.
