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服务容量规划
在上篇Blog里，谈到了SharePoint中的部分容量限制。因为最近比较忙，这次只说安全限制和SharePoint搜索限制。
安全限制
· 推荐不要让一个用户同时属于5,000个以上的group。如果超过这个限制，也没有服务器性能的代价，只是推荐。如果超过，搜索时缓存ACLs的时候会花更多的时间，并且增加了检查安全性的时间。
· 推荐一个站点集的用户数不要超过2,000,000。再说一次，你可以超过这个数，但是如果有那么多用户的话，长远看有管理上的问题。推荐你用PowerShell。
· 推荐一个SharePoint组不要超过5,000个用户或者外部组（AD组）。用户越多，验证权限或者刷屏时所花的时间就越长。
· 不推荐每个站点集有超过10,000个SharePoint组。
· 不推荐在一个ACL里超过5,000个权限项目。
SharePoint搜索限制
谈到搜索，就是一个很大的话题。我强烈建议读完"Estimate performance and capacity requirements for SharePoint Server 2010 Search" (SearchforSPServer2010CapacityPlanningDoc.docx).理解搜索结构是规划容量大小和容量管理的关键。我准备在你开始之前复习一下刚层次的概念：
· 首先在计划时你需要理解什么数据是可搜索的，有多大。你需要知道那些数据怎么样是可用的。你需要知道那些数据怎么保持最新并且人们可以同时搜索到那些数据。这个其实已经更深了，我已经写过关于 FAST5.3的博客。概念是一样的。
· 对于SharePoint2010,有一个搜索生命周期你需要理解的。有一个索引查询，在那里执行数据的完全爬行，取决于被爬行的内容的大小和访问方式。接下来是索引维护，增量爬行所有的内容。最有是索引清理，当内容源改变或者从爬虫中删除的时候有个基本的清理。
· 接下来有一个负责查询数据的查询服务。知道查询等待时间和查询吞吐量很重要。如果你想减少数据搜索的等待时间。
· 真是有很多策略去配制SharePoint逻辑和物理的拓扑结构以满足你的需求。这里有些简单的事情需要考虑。首先不要在同一台机器上同时运行查询和搜索服务。第二，如果你有硬件，也推荐你在一台独立的机器上运行查询服务，这样会降低查询时间并且增加吞吐量。第三，最好有多台建立索引的搜索服务器，这样当有错误或者你需要为搜索某些指定的内容源分配资源时，就有备份了。
· 有一些用来评估你需要的建立索引空间的算法。具体细节阅读这个白皮书。
以下是一些基本的临界值和边界值：
· 推荐你不要把超过20个SharePoint搜索服务的应用程序发布到一个Farm上。
· 对于每一个SharePoint搜索服务，不要超过10个用来存储爬虫数据的爬虫数据库。优化的配置是每个搜索服务4个爬虫数据库。每个爬虫数据库不应该超过250万条数据。
· 推荐每个搜索应用程序不要总体不要超过16个爬虫组件。
· 推荐每个索引服务不要超过20个索引分区。限制是128个索引分区。给索引分区允许创建更小的索引，以加快搜索的速度，但是如果分区太多，作用就会相反。
· 推荐每个搜索索引不要有超过1千万条项目。在一个搜索服务里大概推荐的对所有索引的限制是1亿条项目。
· 推荐每个搜索服务不要有超过10亿条爬虫日志。
· 对于每个搜索服务，推荐不要超过10个属性数据库。属性数据库包含在每个索引分区里的项目的元数据。属性数据库的数量有128个这样的硬性限制。
· 有个硬性的限制，每个搜索应用程序128个查询组件。
· 对于查询范围，每个范围不应该超过100个范围规则。并且你每个搜索服务不应该超过600个范围规则。超过这些界限制将会影响性能。同时，每个网站不应该超过200个范围，这个会再次影响到性能。
· 推荐每个网站不要有超过25个显示组。显示组用来通过用户界面来分组显示范围。超过这个数字将会影响性能。
· 对于警报，每个搜索应用程序限制1M。
· 对于搜索内容源，推荐不要超过50个数据源，但是最高的界限是500个。
· 在同一个搜索服务中的并行爬虫的界限是20；超过这个会导致性能问题。
· 在爬行中，每个搜索应用程序将支持最多50万个属性。
· 推荐每个farm不要超过100个爬虫影响规则。
· 推荐每个搜索服务不要超过100个爬虫规则。这是因为管理员屏幕性能会降低。
· 每个搜索服务管理的属性的界限值是100,000。管理属性用于搜索查询中。基本上爬虫的属性映射到管理的属性上。
· 每个管理属性不推荐有超过100个映射。超过这个会降低爬行速度和查询性能。
· 每个搜索服务将支持每次操作删除100个ＵＲＬ。
· 推荐只有一个最高级别的授权页面和最少的二级三级页面。
· 推荐每个站点集不要超过200个关键字，但是最多是每个站点集5000个。超过这个真正的影响就是管理页面的性能。
· 每个被爬行的项目的元数据属性限制是10,000。
原文地址：http://www.astaticstate.com/2010/06/sharepoint-2010-capacity-planning.html
