Microsoft Solution for Intranets 说明性体系结构规划指南：规划指南

本页内容

	企业门户
	部门级门户
	工作组站点

企业门户

企业门户是一个组织的中央信息源，一个企业门户能够动态支持 1000 名到 20,000 名的用户操作，可以对 100 万个索引文档进行搜索。

为了创建本解决方案所描述的测试方案，我们考察了一些组织，并对它们使用的企业门户的主页进行了检测，以确立我们的性能目标——然后，我们将该性能目标增加到了两倍，将该结果作为我们解决方案的性能目标。它的内容包括：访问门户主页、查看企业通告、执行搜索、以及查看搜索结果。

一般来说，几乎每个组织中的用户在 1 到 2 天的时间内都会至少访问企业门户一次，但是日常活动中用户们在企业门户停留或工作的时间都很短。大多数的访问都是只读性质的，因为只有少数人能够对企业门户进行编辑和修改。企业门户是整个组织范围内的信息的公共来源，比如公告、新消息、日程、某个特定主题或特定部门的 Web 站点目录（工作区、工作组站点等），或者对整个组织范围内信息的索引展开搜索。

通过对门户部署工作进行定量描述，可以估计出必需的峰值吞吐量。以下公式可以得出组织日常操作中每秒钟的峰值吞吐量：

表 4.1 企业门户上每秒钟的峰值操作量

备注： 峰值系数是一个近似数字，表示控制板站点峰值吞吐量超出平均吞吐量的程度。这个数字一般在 1 到 4 之间。上式中的 360,000 是通过以下计算得出的：

100（百分比换算） X 60（每小时的分钟数） X 60（每分钟的秒数）

预计在任何一个给定的日子里，活动用户的数量占公司总的用户数量的 50%。在本指南中，用户操作被规定为：每个用户每天（12 个小时）平均执行 5 次操作。

包括了每个活动用户行为的企业门户配置文件如下：

表 4.2 企业门户配置文件

备注： 查看搜索结果没有包括在内，因为从检索结果列表文档的操作是针对存储该文档的服务器的一个 HTTP GET 请求，而不是针对检索服务器本身的。

备注： 这种类型请求的负载要小于搜索操作的负载，因为在按照本 规划指南中的指导配置企业门户的时候，SharePoint Portal Server 2001（应用了Service Pack 1）服务器的工作区会使用高速缓存技术。

根据这个配置文件，我们可以计算出，根据组织规模的大下，企业门户服务器每秒钟所执行的操作数量应该在0.58到5.79之间。各种操作的负载并不相等。某些操作的负载大于1或小于1，这要根据完成操作所需使用的资源来确定。对门户主页的请求会使用高速缓存技术，该技术是 SharePoint Portal Server 的一个新特性。

返回页首

部门级门户

部门门户代表着组织中以组织形式或地理形式存在的界线。本指南介绍使用 SharePoint Portal Server 来托管门户。所规定的体系结构可以支持拥有 1000 名用户及 50,000 份文档容量的某一部门级门户。

在一个业务部门中，部门级门户可以成为大型工作组的主页和中央信息存储库。主页可以提供新闻、活动公告、链接、搜索、订阅通知和分类信息。部门中的工作组可以在部门门户里存储和管理文档。部门门户的结构灵活，可以支持各种规模大小的工作组以及他们的个人信息管理过程。例如，部门级门户可以支持多种不同类型的文档配置文件、目录结构和文档审批选择。

通过对所部署门户的定量描述，可以估计出必需满足的峰值吞吐量是多少。以下公式可以得出每秒钟的峰值操作吞吐量：

表 4.3 部门级门户钟每秒钟的峰值操作量

备注： 峰值系数是一个近似数字，表示控制板站点峰值吞吐量超出平均吞吐量的程度。这个数字一般在 1 到 4 之间。上式中的 360,000 是通过以下计算得出的：

100（百分比换算） X 60（每小时的分钟数） X 60（每分钟的秒数）

预计每天在部门级门户上活动的用户数量占总用户数量的 80%。在本指南中，每个用户在一天（12 小时）中平均要进行操作被规定为 18 次。使用情况配置及计算机需求如下：

表 4.4 部门门户配置

备注： 上述操作水平是该组织单位中所有用户的平均操作水平。

各个操作的负载并不相同。有些操作的负载大于1或小于1，这要根据完成操作所需使用的资源来确定。比如签出、审核和发布这样的文档管理操作，要比一般的搜索或者门户页面请求操作使用更多的资源。在这种情况下，部门级门户服务器每秒执行大约执行 1.33 次操作。

操作预测代表了每个用户的平均行为，这种预测是我们对 SharePoint Portal Server 用户的操作行为进行认真观察后得出的。但是，某些组织肯定会有更高的文档管理要求，所以我们还提供了一个备用的“重负载”方案。在这个重负载的使用方案中，我们对文档管理有关操作任务的平均行为进行了加倍处理。如果您对这种重负载使用方案感兴趣，那么您需要在部门级门户服务器上每秒平均执行 2 次操作。

返回页首

工作组站点

工作组站点可以帮助项目组和特别小组共享信息。工作组成员可以共享文档、相互沟通，并协同工作以便在截止日期到来之前完成项目。这些小组必须能够容易和不受影响的进行信息共享。本指南介绍了 SharePoint Team Services 主持工作组站点的使用。本文所描述的体系结构可以支持多达 100 个工作组站点，每个站点 10 名用户。这些工作组站点可以分为两种类型：非托管站点和托管站点。

非托管站点是为了满足特别小组的协作而建立的站点。这些站点鼓励用户进行自发协作以及工作组内部的相互沟通。因此，存储在这些站点中的信息不会被内容索引服务器或者部门级服务器进行索引。用户可以开发和共享这些信息，而无需担心其他人会看到这些信息，直到它们准备妥当可供更多人使用为止。

托管站点使用了一些结构化内容。这种类型的内容经常是基于某个项目的，可以为每一个项目都创建一个工作组站点。这些站点中存储了项目文档和协作内容。这种类型的站点能够提供标准的诸如文档库和列表这样的 SharePoint Team Services 内容。因为 SharePoint Team Services 中的文档库并没有提供签入、签出和文档版本控制这些功能，建议您在部门门户服务器上为每一个托管站点创建一个项目文件夹。URL 链接被用于集成来自部门门户文档库和部门工作组站点的内容。每一个托管站点都可以被内容索引服务器的搜索，以便企业门户能够使用这些站点上的内容。此外，托管站点还能够被部门门户的搜索，以便用户也能够通过这些门户访问到托管站点中的内容。

创建工作组站点是非常容易的。相比较而言，由于管理员可以对工作组站点的创建过程加以控制，托管站点的文件夹树要更有条理一些。而非站点的虚拟根目录由于任何用户都可以创建站点，则显得较为凌乱 。自助网站创建插件(Self-Service Site Creation Add-in)允许拥有正确权限的用户无需得到管理员的帮助，就可以直接创建子站点。本指南介绍的体系结构可以容纳大约 50 个托管站点和 50 个非托管站点。

测试方案假定大部分站点用户在某一天中均会使用该站点，并且进一步假设用户在站点上会访问门户主页数次、张贴和检索文档数次，以及阅读和编辑列表数次。

预计在一天之中，各个工作组站点中的 80% 的工作组站点用户会进行活动。在本指南中，规定用户每天（12 个小时）平均进行 30 次操作。

这些操作的配置如下：

返回页首	第 5 页，共 9 页