برنامه ریزی ظرفیت فضا در شیرپونت ۲۰۱۰
SharePoint 2010 Capacity Planning
چه بخواهید سرور شیرپونت خود را به نسخه ۲۰۱۰ Upgrade کنید و یا برای نصب یک سرور شیرپونت جدید برنامه ریزی کنید تخمین اینکه فضای مورد نیاز سیستم چقدر باید باشد و همچنین حداکثر ظرفیت فضای سیستم چقدر است یکی از مهم ترین موارد در طراحی و پیاده سازی Plan شیرپونت است .
برای یک طراحی مناسب لازم که مقیاس دقیق آن را بدست آورید. این پست شامل چندمقاله و همچنین راهنما در همین خصوص است امیدوارم برای شما هم مفید باشد:
The biggest key
| SharePoint 2007 | SharePoint 2010 |
Items per view | 2000 | 5000 |
Documents per library | 5 million | 10 million |
Database size | 100GB | 200GB (up to 1TB for workloads) |
Simultaneous Doc Editors | 1 (no Multi user editing of Word, Excel, PPT) | 10 (max at 99) |
Column | 2000 per doc lib, 4096 per list with (rowOrdinal) | New Row Wrapping (8,000 bytes) |
Content Databases per Web App | 100 | 300 |
App Pools per web server | 8 | 10 |
Indexed (Crawl Count) | 50 Million items per SSP | 100 Million per search Application |
Site Collections per Web App | 50,000 | 500,000 |
Items per view
If there was one thing that was a focus it was list scale. Not only is the list itself much more scalable, and better designed, but also the actual rendering of the lists is more flexible and more manageable. I’ve discussed the list threshold throttling limits where you can control how much is returned in a view. In 2007 we had a recommended limit of 2000. This 2000 number found itself as a key designing principal. Now the default is 5000 and this is as well the recommended max for a view more than doubling the previous limit. I’ve seen examples where this was increased and still the list rendering had much better performance than in 2007. … “Maximum number of list or library items that a database operation, such as a query, can process at one time, outside of the daily time window set by the administrator during which queries are unrestricted.”
Documents per list
While you could put millions of items in lists in SharePoint 2007, due to various issues many were cautious to push the number of documents. Both search depth issues, and rendering were a constant concern around scaling out large document repositories. The limit was 5 million in a list, now we see 10 million item document libraries. “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.” Personally I see the performance in lists more than double in performance and feel much better about the scalability as well due to a variety of things including the re-architecture of the content database. As well the improved support for remote blob storage with SQL 2008 R2 can improve performance on large documents in large environments, while I still caution customers to be careful around these decisions for operations & supportability considerations.
Column Limits
What seems like a decent investment is row wrapping. SharePoint Server 2010 data is stored in SQL Server tables. To allow for the maximum number of possible columns in a SharePoint list, SharePoint Server will create several rows in the database when data will not fit on a single row. This is called row wrapping. Six rows are recommended as a maximum.
Site Collection Sizing
25 to 100GB “A site collection should not exceed 100 GB unless it is the only site collection in the database. Certain site collection actions, such as site collection backup/restore or Move-SPSite, cause large Microsoft SQL Server® operations which can have performance impact or fail if other Site collections are active in the same database.”
Database
Published recommendations go from 2007 as 100GB content databases and in SharePoint 2010 looking at 200GB with possibilities of up to 1TB with careful non collaborative workloads like documents and records repositories. “We strongly recommended limiting the size of content databases to 200 GB to help ensure system performance. Content database sizes up to 1 terabyte are supported only for large, single-site repositories and archives with non-collaborative I/O and usage patterns, such as Records Centers.”
Storage
While structurally the blobs are better managed and more scalable, the fundamental storage story has changed a bit. We had EBS support with SharePoint 2007 SP1, but implementing anything was complex and many cautions against doing anything unless you had support with a vendor and even then, proceed with extreme caution. With SharePoint 2010 and SQL 2008 R2 we have a better story with RBS (Remote Blob Storage) essentially handled transparently by SQL. SharePoint 2010 is happy to have SQL store its blobs on external storage using a provider mechanism.
Databases per Web App & App Pools per Server
Knowing people are using 64 bit hardware you’ll see a few recommendations simply based on better scale with SQL and IIS. Examples of this is the numbers of databases per web app and the number of app pools per server which totally depends on the RAM on the box. SharePoint 2010 by default does not use less memory than SharePoint 2007. For example with App Pools, “This limit is dependent largely upon: 1) The amount of RAM allocated to the front end server 2) The workload that the farm is serving – the user base and the usage characteristics (the process of a single highly active application pools can reach 10 GB or more)”
Index Sizing
“SharePoint Search supports index partitions, which each contain a subset of the entire search index. The recommended maximum is 10 million items for a given partition. The overall recommended maximum number of items: e.g., people, list items, documents, Web pages, etc., is 100 million.”
