Understanding List Performance In SharePoint 2010
There are many great improvements you will find with SharePoint Sever 2010. They make it a better experience for creating and then successfully using lists that are large in size. The problem with SharePoint Server 2007 was that you had to very carefully plan with it and then use a custom code. There were many operations unrestricted though so you could create lists and get some performance that was customized.
SharePoint Server 2010 makes it much easier for you to be able to complete an array of scenarios using a large list. Part of this is due to the out of box features, improvements with written code, and the limits that have been placed on configuration. All of this allows for performance from a large list without it negatively impacting the performance of other users.
Regardless of which content management system you use, implementing a large number of items requires planning as well as proper set up. That is still the case when you use SharePoint Server 2010. There are many variable factors to look at including the experience of users, the information architecture, overall performance, governing the program, and a disaster recovery strategy.
With so much being offered in one list, you need to be able to determine a method for a user to find the items they need from that list. At the same time you need to make sure the performance of the system continually meets the needs of users. A high uptime along with effective management of the large lists are essential for it to all work properly for you.
There are new features including limits and throttles for protecting the performance of the server farm. The content query features including metadata navigating and Web Part allow you to get the work you need through a query for the list. The information here is going to serve as a tool for you to understand the information architecture as well as the features that are available for successful implementation.
Before you get started you will have to decide on some key design options. They are going to affect the way in which you are able to manage a large list. Some of these decisions cover the issues of permission issues, how many columns will be added to a list, how many columns can be viewed at once, and which of the folders and indexes you will use for storing all of it. Such decisions need to be made carefully as they do affect overall performance of the list. As your list grows these decisions will have an even stronger impact.
There are many different design choices for you to consider.
Understanding them will help you to make your final decisions. Then you can feel confident that you have properly designed a way for your large list to be managed. The goal is to make it simple for users to get information quickly. This should be based on user experience as well as the overall needs of the business.
SharePoint Sever 2010 offers support for document libraries as well as huge lists. Some of them have millions of items in them. It is possible for you to create extremely large libraries with the combined use of metadata navigation, hierarchies on sites, standard views, and folders. In order to retrieve data from a large list using CAML queries or list views though you need to have both folders and indexes for the partitions. If you don’t, then only the search mechanism will be able to gain access to the data.
There can be multiple lists for a single document library and each of them can support as much as you need. It all depends on the way in which you organize the folders and documents. It also depends on the size of those documents that have been stored, the amount of storage space, and the number of columns that the document library has been set up for.
In the list view threshold you will have a limit of 5,000 items for queries. This is the way in which the configuration is defaulted. You can change this but it is strongly recommended that you don’t do so. Poor performance overall can occur if the queries are used for lists that have more than 5,000 items included. It is very important that you spend some time exploring the details of List View Threshold and List Views.
The number of unique permissions that are in a list can be increased but when you do so you also decrease performance. The design where most of the content in a large list is unique should be secured. The difference for operations with a list offering from 0 to 1,000 unique permissions is approximately 20%. This would be with a configured default of 50,000 unique permissions for each list.
It is recommended that you lower your limit to 5,000 so that the large lists being used for content have fewer unique permissions in them. This allows for better performance as well as for it to all be better managed.