设为首页 收藏本站
查看: 619|回复: 0

[经验分享] SharePoint 2010 容量规划 (二)‏

[复制链接]

尚未签到

发表于 2015-9-27 11:56:40 | 显示全部楼层 |阅读模式
在上篇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个URL。
·         推荐只有一个最高级别的授权页面和最少的二级三级页面。
·         推荐每个站点集不要超过200个关键字,但是最多是每个站点集5000个。超过这个真正的影响就是管理页面的性能。
·         每个被爬行的项目的元数据属性限制是10,000。

原文地址:http://www.astaticstate.com/2010/06/sharepoint-2010-capacity-planning.html

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-119452-1-1.html 上篇帖子: 在SharePoint 2010上使用AjaxControlToolKit 下篇帖子: SharePoint:扩展DVWP
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表