SharePoint size and limits

Posted by Microsoft on Thursday, December 3, 2009

Entity	Max Permissible Size
Site Name	128 characters
Site URL	255 characters
Display name	128 characters
Connection string	384 characters
Email address	128 characters
Version numbers	064 characters
Virtual Server Friendly Name	064 characters
SQL Database Name	123 characters
SQL Database Column	128 characters
SQL Database Table Name	128 characters
SQL Role Name	128 characters
Server Name	128 characters
Windows User Name	300 characters
Windows Password	300 characters
Dependencies per object	032 objects
Zone enumeration value	004 zones
Default SQL command timeout	300 seconds
Number of simultaneous workflows that can be run	015

Site object	Guidelines for acceptable performance	Notes	Scope of impact when performance degrades
Site collection	50,000 per Web application	Total farm throughput degrades as the number of site collections increases.	Farm
Web site	250,000 per site collection	You can create a very large total number of Web sites by nesting the subsites. For example, 100 sites, each with 1000 subsites, is 100,000 Web sites. The maximum recommended number of sites and subsites is 125 sites with 2,000 subsites each, for a total of 250,000 sites.	Site collection
Subsite	2,000 per Web site	The interface for enumerating subsites of a given Web site does not perform well as the number of subsites surpasses 2,000.	Site view
Document	5 million per library	You can create very large document libraries by nesting folders, using standard views and site hierarchy. This value may vary depending on how documents and folders are organized, and by the type and size of documents stored.	Library
Item	2,000 per view	Testing indicates a reduction in performance beyond two thousand items. Using indexing on a flat folder view can improve performance.	List view
Document file size	50MB (2GB max*)	File save performance is proportional to the size of the file. The default maximum is 50 MB. This maximum is enforced by the system, but you can change it to any value up to 2 GB.	Library, file save performance
List	2,000 per Web site	Testing indicates a reduction in list view performance beyond two thousand entries.	List view
Field type	256 per list	This is not a hard limit, but you might experience list view performance degradation as the number of field types in a list increases.	List view
Column	2,000 per document library4,096 per list	This is not a hard limit, but you might experience library and list view performance degradation as the number of columns in a document library or list increases.	Library and list view
Web Part	50 per page	This figure is an estimate based on simple Web Parts. The complexity of the Web Parts dictates how many Web Parts can be used on a page before performance is affected.	Page

The following table lists the recommended guidelines for people objects.

People object	Guidelines for acceptable performance	Notes
Users in groups	2 million per Web site	You can add millions of people to your Web site by using Microsoft Windows security groups to manage security instead of using individual users.
User profile	5 million per farm	This number represents the number of profiles which can be imported from a directory service, such as Active Directory, into the people profile store.
Security principal	2,000 per Web site	The size of the access control list is limited to a few thousand security principals (users and groups in the Web site).

The following table lists the recommended guidelines for search objects.

Search object	Guidelines for acceptable performance	Notes
Search indexes	One per SSPMaximum of 20 per farm	Office SharePoint Server 2007 supports one content index per SSP. Given that we recommend a maximum of 20 SSPs per farm, a maximum of 20 content indexes is supported. Note that an SSP can be associated with only one index server and one content index. However, an index server can be associated with multiple SSPs and have a content index for each SSP.
Indexed documents	50,000,000 per content index	Office SharePoint Server 2007 supports 50 million documents per index server. This could be divided up into multiple content indexes based on the number of SSPs associated with an index server.
Content sources	500 per SSP*	This is a hard limit enforced by the system.
Start Addresses	500 per content source*	This is a hard limit enforced by the system.
Alerts	1,000,000 per SSP	This is the tested limit.
Scopes	200 per site	This is a recommended limit per site. We recommend a maximum of 100 scope rules per scope.
Display groups	25 per site	These are used for a grouped display of scopes through the user interface.
Crawl rules	10,000 per SSP	We recommend a maximum 10,000 crawl rules irrespective of type.
Keywords	15,000 per site	We recommend a maximum of 10 Best Bets and five synonyms per keyword.
Crawled properties	500,000 per SSP	These are properties that are discovered during a crawl.
Managed properties	100,000 per SSP	These are properties used by the search system in queries. Crawled properties are mapped to managed properties. We recommend a maximum of 100 mappings per managed property.
Authoritative pages	200 per relevance level	This is the maximum number of sites in each of the four relevance levels.
Results removal	100	This is the maximum recommended number of URLs that should be removed from the system in one operation.
Crawl logs	50,000,000	Number of individual log entries in the crawl log.

The following table lists the recommended guidelines for logical architecture objects.

Logical architecture object	Guidelines for acceptable performance	Notes
Shared Services Provider (SSP)	3 per farm (20 per farm maximum)
Zone	5* per farm	The number of zones defined for a farm is hard coded to 5.
Web application	99 per SSP	This limit includes the number of Web applications on child farms consuming resources on this SSP.
Internet Information Services (IIS) application pool	8 per Web server	Maximum number is determined by hardware capabilities.
Site collection	50,000 per Web application
Content database	100 per Web application
Site collection	50,000 per database

The following table lists the recommended guidelines for physical objects.

Physical object	Guidelines for acceptable performance	Notes
Index servers	1 per SSP*
Application servers running Excel Calculation Services	No limit
Query servers	No limit	Because 100 content databases are supported for each query server, the number of query servers required per farm is based on the number of content databases in the farm. For example, if there are 500 content databases in your farm, you will need at least 5 query servers.
Web server/database server ratio	8 Web servers per database server	The scale out factor is dependent upon the mix of operations.
Web server/domain controller ratio	3 Web servers per domain controller	Depending on how much authentication traffic is generated, your environment may support a greater number of Web servers per domain controller.

WSPBuilder for SharePoint 2010 in Visual Studio 2010

@keutmann announced the release of WSPBuilder 2010 BETA 1.1 today available here to download from CodePlex.

My first impressions with WSPBuilder for SharePoint 2010 environment are that the functionality looks inferior to the out of the box toolset. This is testament to the guys at Microsoft finally focusing on this stuff! There are some great videos on Channel 9 that explore these tools.

WSPBuilder is a great tool for SharePoint 2007 environments as it simply fills the void of functionality not provided by VSeWSS 1.2 (yes 1.3 is still in CTP!) and it supports Visual Studio 2005, 2008 and 2010 helping the armies of developers not yet on the latest and greatest!

I personally really appreciate all the hard work @keutmann has put into developing WSPBuilder...it has saved me hours over the years developing on SharePoint 2007.

SharePoint 2007 support too! More info on SharePoint 2007 support here

I've have written an overview here of the features of WSPBuilder 2010 BETA 1.1 for SharePoint 2010 environments below.

WSPBuilder appears as a separate category of Projects in Visual Studio 2010

The base project has a SPHive and GAC folder

The Project Items available to add in BETA 1.1 are:

• Web Part Feature
• Blank Feature
• Sequential Workflow Feature
• State Machine Workflow Feature

WSPBuilder Menu

The menu has the same options but has added keyboard short cuts for each.

WSPBuilder Build Output

It detects the SharePoint environment and outputs it for SharePoint 2010.

WSPBuilder Manifest.config

The manifest.config file allows you to customise the process for building the WSP. This includes adding dependent solutions and assembly redirects.

Web Part Feature

WSPBuilder adds project items to various areas to create the Web Part instance. Creating additional web parts will create individual Features.

The Event Receiver it creates does not include the FeatureUpgrading new Event for SharePoint 2010.

Blank Feature

The feature.xml file Version states 12.0.0.0 on first creation

Sequential Workflow

This currently has an error in it.

This is the base elements.xml file it generates for the workflow too.

State Machine Workflow

This currently has an error in it.

This is the base elements.xml file it generates for the workflow too

Introduction to SharePoint Designer 2010

Microsoft SharePoint Designer 2010 (Beta) allows Designers – non-programmers - and, encourages, Developers, and I mean encourage, to build web based applications on SharePoint’s latest platforms (SharePoint Foundation 2010 and SharePoint Server 2010).

To start, you must locate SharePoint Designer 2010 in the Microsoft Office application group – its default location.

One of the great things about the, new, SharePoint Designer 2010 experience is the initial start. Immediately, the user (Designers and Developers) is provided visual feedback upon the start of the application. It is my experience that the loading is rather quick versus the experience with the previous version, SharePoint Designer 2007.

After SharePoint Designer 2010 (Beta) initially starts, you will notice that there are two primary focuses. The user has the option to Open a SharePoint Site or Create a New SharePoint Site. The new initial UI is a far step from the traditional experience of SharePoint Designer 2007. In fact, the user does not need to browse around the interface attempting to introduce them to the application. It is all there front and center.

In contrast, the fact that there is an option to use SharePoint Designer 2010 (Beta) on the My Site is discouraging. In another blog posting we will discuss the new features available on the, new, SharePoint 2010 platforms that afford the SharePoint administrators and Site Collection Administrator better control now is not the time to dive into those features, also, we will focus on the various options in more detail in a future blog as a part of this series.

After, either, Opening the Site or Creating a New Site, the user is presented with the Site Setting information page. Of course, the most notable change, in the SharePoint Designer 2010 UI, is the presentation of the, new, Ribbon. Again, I will dive deeper in the various features afforded by the Ribbon in a later blog as a part of this series.

The Settings Page provides a significant amount of information , such as, the Site Information, Permissions, SubSites, also known as Webs, Settings and Customization. The fact that this Designer Dashboard, yes, I called it a dashboard, and no it isn’t Microsoft’s official terminology, is forthcoming with quite a bit of information. This information was, either, lacking or wasn’t as easy to obtain in SharePoint Designer 2007. Again, we will dive deeper into many of the features during this series in a future blog. Although the tab interface is not new to SharePoint Designer 2007, I find the tab interface in SharePoint Designer 2010 (Beta) a bit more inviting and user friendly.

Lists and Libraries are nested in a simple view in SharePoint Designer 2010 (Beta). It is more similar to a report versus a hierarchical structure, as leveraged in SharePoint Designer 2007. Also, I want to encourage you to focus on the changes in the context of the Ribbon’s interface as we navigate from the Site Settings page. Of course, we can witness a heavy use of the bread crumbs in the SharePoint Designer 2010’s interface. The bread crumb was presented as a simple navigation control in the SharePoint Designer 2007 interface. Again, there was an emphasis on the hierarchical structure.

Workflows are also presented in a report form. The Workflows’ report provides summary information referencing workflows leveraged by the site or web. In the SharePoint Designer 2007 interface, Workflows were presented nested in a Workflow library or folder, depends on whom you ask. Again, there is an emphasis on the actual artifacts’ hosted on the SharePoint 2010 platform. Of course, there is a significant amount of new features for SharePoint Designer 2010 (Beta) and its capabilities to build flexible workflows. Again, we will dive deeper into those capabilities through-out this blog series.

The Site Pages provides summary information about located in the Sites Pages Library. The Site Pages Library is used to create and store pages for a specific Site or Web.

The Site Assets provides a reports view of files that are included on the pages of a Site or Web. In the SharePoint Designer 2007 UI, the storage locations for files included on the pages were stored in a number of locations, such as, the images folder.

The Content Types page provided a summary report about the various collection of content types, leveraged by the Site or Web, to establish consistent management of content. Immediately, you will find information, such as, Group, Parent, Source and Description. Most importantly, the UI provides quick access to manage the various content types. SharePoint Designer 2007 did not afford users this type of reporting feature. We will explore this new feature further as a part of this blog series.

The Site Columns UI provides a summary report referencing a collection of columns available to Lists, which includes, Column Name, Type, Group and Source. In the SharePoint Designer 2007 UI we did not have a central presentation of the linked columns for a Site or Web.

The External Content Types summary reports provides information, such as, Display Name, Name, External System, Type and Namespace, about External Lists, also known as SharePoint Lists, that exposes data from various back-end repositories – databases, web services and other Line-of-Business applications. The beauty of it all is that this feature is provided in the SharePoint Designer 2010 UI.

The Data Sources summary report provides information, Name, Type and Description, about the various data sources available to the Site or Web. The report is categorized based on type, for instance, Lists and Libraries. Again, this is a great presentation in the UI so that users are not required to leverage the hierarchical structure to obtain the information similar to the SharePoint Designer 2007 UI.

The Master Pages summary report provides information, Name, Title, Content Type, Size, Modified Date, Modified By and Comments, about all of the artifacts, Master Pages, Page Layouts, images and xml files, found in the Master Page Gallery.

The Site Groups summary report provides some information, Group Name and Description, about the various Groups with, some level, of access to the Site or Web. You have to ask yourself, where are the contributor settings. Again, we will dive deeper into the many changes in a later blog.

The SubSites summary reports provide a list of the Sites or Webs within the hierarchical structure. The report provides information, such as, Site Name, URL and Modified Date.

Finally, the All Files provides a summary report of all content for a Site or Web, which includes the SubSites. The information provided includes, Name, Title, Size, Type, Modified Date, Modified By and Comments. The significance here is users have a more efficient way to ascertain the information about the artifacts that make up SharePoint 2010 sites.

The overarching selling point is that SharePoint Designer 2010 encourages rapid building and deployment of, web-based, solutions that meet business needs, leveraging the various features – lists, content types, workflows and a number of other features – of an organization. Here is the catcher, there is no-coding. Included in this blog series, I will work to cover the various use cases and features.

Using Visual Studio 2010 SharePoint Templates to deploy a web part in SharePoint 2007

That’s a mouth full. I always suspected it was possible to use Visual Studio 2010 to package up my SharePoint web parts and other artifacts into a solution (.wsp file) and turn around and deploy that code into MOSS 2007. Today I gave it a try and it actually works pretty well. This post will show you how to do it. I will remind you that you won’t be able to take advantage of any of the automatic deployment, debugging features built into Visual Studio 2010 and SharePoint 2010, but you will have a nice solution file that was built automatically without having to use a third party tool like WSPBuilder. You can then take the solution package and deploy it to SharePoint with stsadm.

I will start off by using the SharePoint 2010 Empty Project Template. Now, unfortunately, the wizard that starts this project has a dependency on SharePoint 2010. It simply won’t run without it. However, if you happen to already have a copy of a project that has been created, you can open an existing SharePoint 2010 project template on a computer that does not have SharePoint installed. I have attached a copy of my Visual Studio solution for you to use as a starting point if you need it.

Once I have my project open, I proceed to create a web part as shown below in the Solution Explorer.

I don’t have to make any modifications to the class. So I add some simple “Hello, World!” code to it.

We’re targeting SharePoint version 3, so that means we need to change some references. All of the DLLs in SharePoint 2010 are version 14. We need version 12 DLLs. So what you will need to do is go get a copy of Microsoft.SharePoint.dll (and possibly Microsoft.SharePoint.Security.dll) from your version 3 SharePoint farm. We then need to remove the reference to the version 14 DLLs. Click on Microsoft.SharePoint.dll and Microsoft.SharePoint.Security.dll and remove them from the solution. We then add our version 12 DLLs to the references list and we’re ready to compile our web part for WSS3.

At this point, I will remind you of the caveats of perusing this completely unsupported approach. Obviously, you can’t need to make sure you are only using API calls from version 3. Using a class from SharePoint 2010 is obviously not going to work.

Build your project and it should compile successfully. Now, I figured everything would work at this point but I discovered one thing that I had to change in this process. The SharePoint 2010 solution schema has a new attribute called SharePoint version on the SharePoint element. WSS3 does not like this.

Luckily, I discovered, that if we delete the value from the property window, it actually removes the attribute.

Simply, remove the value there and we are ready to package the project.

When this is complete, you can browse the file system and find your .wsp file in the bin folder. Copy the .wsp file to the SharePoint 2007 server if you aren’t already on it. Then add and deploy the package with stsadm. At this point, you will have a feature that you can activate on your SharePoint 2007 server. Go to site collection features and activate it.

The web part should now be in the Solution Gallery. Now edit a page, and add a new web part. Your web part should be in the group labeled Custom assuming you haven’t changed it.

We can now verify that the web part code works on the page.

As you can see it’s really pretty easy to build a WSS3 web part in Visual Studio 2010 and deploy it. We lose some of the cool VS2010/SP2010 integration features of course, but the fact it builds the package for us is a huge win. Not to mention, upgrading our code to work in SharePoint 2010 later will be pretty easy since all we have to do is change our references from the version 12 to the version 14 DLLs. I’ve only covered how to do a web part here today. I suspect other SharePoint Project Items will work as well. I’ll try them out soon and let you know how they work. As a reminder, I have attached a copy of my solution to this post for you to use in case you don’t have SharePoint 2010 installed any where. Give it a try and let me know if it works for you.

Creating a SharePoint 2010 Visual Web Part using Visual Studio 2010

First thing you need to do is open Visual Studio as an Administrator. You need to do this when you are programming against SharePoint because the debugger & tools need Administrator access to SharePoint. Visual Studio will warn you if you forget.

Next create a new project and select SharePoint 2010 -> Visual Web Part. (Make sure you select Visual Web Part and not Web Part). Name the project LowInventoryWebPart. The SharePoint Customization Wizard opens. Select your SharePoint site, in my case I’ve created a team site called Northwind.

Notice that “Deploy as a farm solution” is the only option. This means that when you design a visual web part it is available to all site collections on the farm as opposed to a sandboxed solution which is only available at the site collection level. The key difference between these two is what processes they run in, farm being the IIS worker process, which dictates which access levels they have. For more information on the differences see Differences Between Sandboxed and Farm Solutions in the MSDN library.

Click Finish and the the ASP.NET designer opens and displays a web user control that we can design. But first we need to add a service reference to our data service. If you recall we are exposing our line-of-business data (in this case the Northwind SQL database) over WCF-REST using a data service. As long as we can access this service from our SharePoint instance once we deploy, then we’re good to go.

To add a Service Reference to the data service, select Project -> Add Service Reference. If your data service is in the same solution as in the case of this one, just click Discover to browse the types that the data service exposes. Set the Namespace to NorthwindService and click OK.

Designing the Visual Web Part and Loading Data

I don’t have any super-fancy design skillz here so we’re just going to create a data-bound GridView and then write a LINQ query to get the low inventory items to display. The key takeaway is that this would be the same code to write if we were writing any ASP.NET webpage, you can even use the Ajax controls in the toolbox. In the next section below we’ll take advantage of the SharePoint server model in order to interact with SharePoint lists, but to pull data from our LOB database it’s standard data access stuff.

So from the Data tab in the toolbox, I’m going to drag a GridView onto the form. I’m also going to drop a Label at the bottom of the form to display any errors or messages. I can style these controls how I like and these styles will be displayed the same way in the Web Part in SharePoint.

Right-click on the designer to open the code-behind. In the Page_Load event handler we’ll write the code to load the low inventory from our data service:

Imports System
Imports System.Web.UI
Imports System.Web.UI.WebControls
Imports System.Web.UI.WebControls.WebParts
Imports LowInventoryWebPart.NorthwindService

Partial Public Class LowInventoryWebPartUserControl
 Inherits UserControl

 Protected Sub Page_Load(ByVal sender As Object, ByVal e As EventArgs) Handles Me.Load
     'Webpart Code to display Low Inventory:
     Try
         Dim ctx As New NorthwindEntities(New Uri("http://myserver/Northwind.svc/"))

         Dim result = From p In ctx.Products _
                      Where p.UnitsInStock <= p.ReorderLevel _                         Order By p.UnitsInStock


         Me.GridView1.AutoGenerateColumns = True
         Me.GridView1.DataSource = result.ToList()
         Me.GridView1.DataBind()

     Catch ex As Exception
         Me.Label1.Text = ex.ToString
     End Try
 End Sub

End Class

Debugging the Web Part

Let’s test this so far. Set the LowInventoryWebPart project as the startup project of your solution (if it isn’t already) and set a breakpoint on the LINQ query. Hit F5 and Visual Studio will recycle the IIS worker process, package & deploy & activate the feature, and attach the debugger automatically for you. This is shown in the Output window and it’s fun to watch so you may want to pin that window open. :-)

------ Deploy started: Project: LowInventoryWebPart, Configuration: Debug Any CPU ------

Active Deployment Configuration: Default

Run Pre-Deployment Command:

Skipping deployment step because a pre-deployment command is not specified.

Recycle IIS Application Pool:

Skipping application pool recycle because no matching package on the server was found.

Retract Solution:

Skipping package retraction because no matching package on the server was found.

Add Solution:

Adding solution 'LowInventoryWebPart.wsp'...

Deploying solution 'LowInventoryWebPart.wsp'...

Activate Features:

Activating feature 'Feature1' ...

Run Post-Deployment Command:

Skipping deployment step because a post-deployment command is not specified.

========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========

========== Deploy: 1 succeeded, 0 failed, 0 skipped ==========

The nice thing is that Visual Studio handles all the deployment as well as all the cleanup. When you close the debugger the feature is deactivated and the package is retracted and deleted. Notice that you can also specify pre and post deployment commands, plus a whole lot more. The Feature and Package designers are very flexible. (For more information watch this Channel 9 Interview: SharePoint Feature and Package Designers in Visual Studio 2010 and read Packaging and Deploying SharePoint Solutions in the MSDN library.)

In order to debug this sucker we first have to add it to a page on our site. When the debugger starts up, it opens a page to the site we specified in the SharePoint Customization Wizard in the beginning. So select Site Actions in the upper left, then Edit Page. Select the Insert tab on the Ribbon and click Web Part. Select the Custom category and you should see your web part. Select it and click Add on the bottom right of the section.

At this point you should hit your breakpoint. Hit F11 and the query will return the low inventory so you can see the data as you design the page. The Page_Load will get called a couple times when designing the web part so keep that in mind.

Next drop down the LowInventoryWebPart menu at the top right of the web part and select Edit Web Part to open the properties. Set the Title to “Low Inventory” and click OK. On the Page tab on the Ribbon select Save to save and close the page editor. Now we’ve got a nice looking web part for browsing low inventory. Sweet!

Close the browser window and this will close your debugging session, recycle the IIS app pool, deactivate the feature and retract the solution automatically for you. These steps are also displayed in the Output window.

Interacting with SharePoint using the Server Object Model

Well that was pretty easy to incorporate our LOB data into SharePoint with a simple web part and a data service but what if the user sees a critically low item and wants to add an item to the Task list? It would be nice if they could do it right here. The way we interact with SharePoint in a Visual Web Part is via the SharePoint Server Object Model. There are also SharePoint client object models as well; one for Silverlight clients and one for other .NET Framework clients. But because we are on the server when we are running a web part, we have access here to the server object model.

So let’s add a TextBox and a Button to our web part that allow the user to enter tasks directly onto the Task list. Go back to design mode on the Web Part, hit enter under the GridView and and type “Create Task:” under it. From the Standard tab on the toolbox, drag a Textbox onto the form then drag a Button and set its Text property to “Add”.

Double-click on the button and we can write this code in the Button1 click event handler to add a Task:

Protected Sub Button1_Click(ByVal sender As Object, ByVal e As EventArgs) Handles Button1.Click
 'Webpart code to Add to task list
 Try
     Dim mySite As SPWeb = SPContext.Current.Web
     Dim listItems As SPListItemCollection = mySite.Lists("Tasks").Items

     Dim item As SPListItem = listItems.Add()

     item("Title") = Me.TextBox1.Text
     item("Assigned To") = mySite.AllUsers(Me.Context.User.Identity.Name)

     item.Update()
     Me.TextBox1.Text = ""
     Me.Label1.Text = "Your task has been added to the task list"

 Catch ex As Exception
     Me.Label1.Text = ex.ToString
 End Try
End Sub

The way we access the current SharePoint site by using the SPContext object and getting the Current.Web. Just like you have an HttpContext in ASP.NET development you have a SPContext in SharePoint development. So let’s test this one out. Put a breakpoint on the Button1_Click handler and hit F5 to deploy and debug. The second time around you don’t need to add the web part to the site page again but it will be refreshed with our new controls and code.

Now create a task by entering a description and click the Add button. The breakpoint will hit and you can debug the code and explore some of the server object model.

When you’re done, navigate to the task list to see that your task has been added.

This project is included in the Northwind OBA solution for VS2010 located here http://code.msdn.microsoft.com/OBANorthwind so have a look. If you’re an ASP.NET developer just getting started with SharePoint development there’s still a lot to learn, but fortunately Visual Studio 2010 can help make an unfamiliar platform easier to approach with the right tools in hand.