SharePoint 2010 容量规划 (二)‏

最新推荐文章于 2024-11-09 21:51:58 发布

crazysharepoint

最新推荐文章于 2024-11-09 21:51:58 发布

阅读量649

点赞数

分类专栏： SharePoint 2010 文章标签： sharepoint 2010 数据库 powershell performance 服务器

SharePoint 2010 专栏收录该内容

26 篇文章 0 订阅

订阅专栏

在上篇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个显示组。显示组用来通过用户界面来分组显示范围。超过这个数字将会影响性能。