SharePoint 2010 容量规划 （一）
简介
要规划，管理和控制一个SharePoint2010 环境，其中最重要的一件事就是要弄明白那些影响性能与维护的边界和临界值。当建设一个新的SharePoint 2010的环境的时候，容量规划就变得极为重要。很多时候，人们在设计SharePoint环境或创建SharePoint解决方案的时候，完全忘了如何将容量规划与使用案例或业务场景联系在一起。知道你的界限在哪里和怎么规划增长它将会影响到你的物理拓扑结构和逻辑拓扑结构。
对于SharePoint 2007, 我们已经有一个容量规划工具（可以从这篇文章里了解到旧工具）。旧工具完成完整这项工作，但还没有新的。但是，实际上微软已经发布了大量的信息，你可以用来做SharePoint 2010的容量规划。
在这篇博客里，我将涉及到
· Web Site和Site Collection的容量规划
· Content Database容量规划
· List和Library容量规划
资源
我用到以下的资源作为分析：
· SharePoint 2010 Capacity Planning (Boundaries and Limits) Whitepaper（查看）。这真是一个很好的白皮书，你应该把它用来作为构建你的SharePoint 2010环境的基线。我知道长远来看将会有创造性的解决方案超过他，但它是个最好的开端。我很喜欢阅读它。
· SharePoint Server 2010 performance and capacity test results and recommendations（查看）。这是一套进入如何测试SharePoint2010的具体细节的白皮书，提供了大量的非常具体的推荐信息。
Web Application限制
· 每个web application的Content Database限制在300。这个很重要，因为一个管理好的SharePoint环境不会只有一个很大的Content Database; 相反，会有很多便于备份和恢复的Content Database. 如果你有很多Content Database, 推荐你用PowerShell去权利web application，而不是用管理界面。
· Zone有个五个硬性的界限（default, intranet, extranet, internet和custom）；这点没有什么新内容。
· 推荐你不要再没有测试过就使用超过10个managed paths.
Web Server 和Application Pool限制
· 推荐每台web server上不要超过10个application pool.这个由内存数量和被用户已使用的容量驱动的。
Content Database 限制
· Content Database不应该有超过200GB的数据。SharePoint 2010确实可以按比例增加到1TB，但是那只是推荐给大的，单一的站点存储的。
· 远程BLOB存储（RBS）访问从第一个字节的数据开始不能超过20毫秒。
Site Collection限制
· 推荐每个站点集不要拥有超过250，000个站点。基本上，就是在创建和删除的站点的时候有性能的消耗。如果你有一个很动态的SharePoint网站，这里很多站点会经常地被创建和删除，你将会遇到全面的性能的问题。
· 站点集不应该超过100GB。问题就是为了让备份和恢复的过程快速运行。
SQL 服务列限制
· 我们需要把换行的数量限制在6行。根据SQL Server的临界值每行64列，那么在你的SharePoint列表或文档库的定义中不应该超过384列。
· 每行存储SharePoint项目的数据量不能多于8000字节。
· 这个白皮书通过SharePoint列类型指定大小的限制。
网页限制
· 不推荐每个SharePoint使用超过25个web part
列表和文档库限制
了解SharePoint列表和文档库容量极为重要，尤其是SharePoint2010新改进的内容。
以下是一些细节：
· 对于SharePoint列表或文档库项目中的每一行，固定的最大值是8000字节。这意味着一个列表项存储在一个列表项的列的数据量最多不能超过8000字节。
· 文件最大为2GB。默认值是50MB。
· 推荐每个文档库中的文档数量不要超过30，000，000。
· 推荐每个SharePoint列表中的项目不要超过30,000,000。
· 在Content Database中，存储列表或文档库项不应该超过6个表格行。这意味着如果你的列表或文档库定义中有很多列，SharePoint将打破多行的数据存储。SQL表中固定的列的数量，如果有更多的列表列，SQL表列会存储在多行中。所以，只有在你的SharePoint列表定义中有几大数量的列的时候，这才会是个问题。
· SharePoint列表用户界面每次只允许批量处理100个项目。
· SharePoint列表查询每个查询中最多允许有8个连接。如果在查询语句中有多于8个查询，就会block.
· 列表视图默认临界值允许有5，000个项目。如果超过这个，你将会遇到性能非常差的查询，总体上吞吐量会降低。Auditor/Administrator的列表视图临界值是20,000个项目。
· 每个站点不要有超过2,000个子站点。如果一个网站有超过2,000个子站点, 一些OOTB的页面，控件和网页控件的性能将会降低。
· 建议不要有10个用户同时去编辑一个文档。要是超过了10个人，在提交文档的时候，你会收到性能相关的问题。刚性边界时99个用户
· 从数据视图中把数据导出到Excel的时候，有个硬性限制，只能导出50,000个项目。
· SharePoint Workspace有硬性限制，不能同步30,000个项目
以下有一些其它的建议你应该知道的：
· 下面是计算列表的可能大小的基本的方法。首先估计要存储的一个文档的平均大小，再乘以这个文档的版本数，然后乘以20%。也建议增加一个合适的缓冲值。
· 当设计怎么在列表中存储内容时，你需要考虑到是把数据存储单独一个列表，还是多个列表，甚至是不同站点集中的多个列表中。在这个文档（DesigningLargeListsMaximizingListPerformance.docx）的"Single list, multiple lists, or multiple site collections"章节有对这个问题的具体讨论。
· 尽管列表和文档库能存储大量的内容，我们还是需要找回他们。微软推荐从大的列表中检索数据的时候，使用列表视图或者CAML查询，他们被区分为文件夹，索引或者两者同时存在。否则，最好并且有效的检索方法就是通过搜索了。
· 一个文档库上赋给了太多的权限也会降低性能。如果你在大量的文档上赋给项目级别的权限，那会更糟。有个配置可以把一个列表的唯一权限数量限制在50，000，但是推荐降低到5,000.
· 我之前提到过换行以及为什么用它。推荐使用在有大量数据的列表中，不要超过1到2个额外的行。
· 查找列可能是另一个有性能问题的根源。
未完待续，在之后的blog里将继续涉及到
· Search容量规划
· Security容量规划
· 社会网络容量规划
· User Profile service和社会网络容量规划
· Web Analytics容量规划
· 工作量容量规划
· Excel服务容量规划
· Performance Point服务容量规划
· InfoPath服务容量规划
· Visio服务容量规划
· Word自动服务容量规划
· Office Web应用程序服务容量规划
· Access服务容量规划
原文地址：http://www.astaticstate.com/2010/06/sharepoint-2010-capacity-planning.html
