规划软件边界 (Project Server)

更新时间: 2009年5月

 

上一次修改主题: 2015-03-09

本文内容:

  • 测试环境

  • 测试结果

  • 可接受性能的指导标准

本文提供相关信息来帮助您了解所测试的 Microsoft Office Project Server 2007 性能和容量限制,并且列出了有关测试环境和测试结果的信息,同时还给出了可接受性能的指导标准。使用本文中的这些信息可以确定您规划的部署是否在可接受的性能和容量限制范围之内。

本文提供的测试结果和指导标准适用于单个安装的 Office Project Server 2007。向这种安装中添加服务器计算机并不会提高可接受性能的指导标准一节的表中所列网站对象的容量限制。另一方面,添加服务器计算机确实会提高服务器场的吞吐量,当网站对象数量较多时,这对于达到可接受的性能是必需的。在某些情况下,如果需要在解决方案中有很多对象,则可能需要使用多个服务器场。

在本文中,指导标准由性能决定。换言之,您可以超过所提供的指导标准,但是随着您扩大规模,您会体验到性能的降低。

请注意,在给定的环境下,有多种因素会影响性能,并且每种因素可在不同方面影响性能。本文中一些测试结果和建议所涉及的功能和用户操作可能在您的环境中并不存在,因此可能不适用于您的解决方案。只有对您的环境进行完全彻底的测试,才可以获得有关您的环境的准确数据。

因为 Office Project Server 2007 基于 Windows SharePoint Services 3.0,所以影响 Windows SharePoint Services 3.0 的性能和容量的大多数因素也会影响 Office Project Server 2007。有关 Windows SharePoint Services 3.0 的容量和性能规划的详细信息,请参阅性能和容量规划 (Windows SharePoint Services)

测试环境

为提供高级别的测试结果详细信息,已将多个服务器场配置用于测试,其中包括一台执行 Web 服务器和应用程序服务器角色的服务器计算机,一台或两台客户端计算机及单独一台运行 Microsoft SQL Server 2000 数据库软件的数据库服务器计算机。已对单独的应用程序服务器计算机执行了特定测试。在测试实验室中还采用了专用域控制器计算机。所有服务器计算机均为 32 位。

下表列出了在测试环境中执行各个角色的计算机的规格。

计算机角色 规格

Web 服务器和应用程序服务器

4 个 AMD Opteron 2.2 千兆赫 (GHz) 处理器,2 千兆字节 (GB) RAM

应用程序服务器

4 个 AMD Opteron 2.2 GHz 处理器,2 GB RAM

数据库服务器

4 个 Intel Xeon 1.5 GHz 处理器,4 GB RAM

客户端

1 个 Pentium D 3 GHz 处理器,2 GB RAM

域控制器

2 个 Pentium III 1 GHz 处理器,512 兆字节 (MB) RAM

提示

根据测试过程中 CPU 和内存的使用情况,域控制器相对较低的规格不会造成相当大的瓶颈问题。

在服务器场计算机之间采用 100 兆位的以太网。

测试结果

下列图表、图形和表展示了测试环境如何执行给定服务器配置、用户操作和负载状况。提供的结果适用于所有类似的 Office Project Server 2007 环境。

提示

以后将测试其他配置。在得出测试结果时将发布这些测试结果。

其他操作的性能指标取决于项目文件的大小、给定项目中所包含基线的数量,以及服务器场的吞吐量等因素。例如,一个小项目文件(小于 1 MB)可能仅需不足 1 秒的时间就可以完成保存,而一个 50 MB 的项目文件可能需要 1 分钟以上的时间才能完成保存,时间长短取决于服务器场配置和网络延迟情况。

项目大小测试标准

下表介绍了用于测试的三个不同大小的项目文件。

大小 文件大小 (MB) 任务数 资源数 工作分配数

0.896

10

10

10

2.03

1,420

94

向实际资源分配的工作 1,486 个,未分配的工作 380 个

8.139

10,422

2

向实际资源分配的工作 5 个,未分配的工作 7,693 个

Active Directory 同步

执行此测试的目的是度量 Active Directory 目录服务同步的性能如何随资源数量的增加而降低。

Windows SharePoint Services 3.0 可为 Office Project Server 2007 提供基础安全和用户管理体系结构。若要将域用户作为 Office Project Server 2007 中的资源进行管理,则必须使域的 Active Directory 与服务器场中任一服务器上的 Windows SharePoint Services 3.0 同步。

Active Directory 同步不会显示关于导入资源数的线性复杂度。复杂度大致呈二次方分布,Windows SharePoint Services 3.0 与 Active Directory 之间的同步说明了此规律。根据测试结果,我们可以估算出包括 20,000 工位的组织进行 Windows SharePoint Services 3.0 同步将需要约 28 小时来测试硬件。包括 40,000 工位的组织将需要约 109 个小时(4.6 天)才能完成 Windows SharePoint Services 3.0 同步。请注意,这些估算是根据此测试的硬件和网络所用规格得出的。

通常,将资源库的大小增加一倍所需的时间几乎是给定服务器场配置和网络带宽的 Active Directory 同步所需时间的四倍。对于一个超大型组织来说,无论其硬件如何,第一个 Active Directory 同步作业可能要运行数天。

下图展示了随着资源数量的增加,完成 Active Directory 同步所需时间的变化情况。

Active Directory 同步图形

有关 Active Directory 与 Office Project Server 2007 之间的同步的详细信息,请参阅在 Project Server 2007 中管理 Active Directory 同步

基线对性能的影响

Office Project Server 2007 允许多达 11 个基线保存在某个给定项目中。随着项目中基线数量的增加,将在很多方面对性能产生影响。之所以执行测试,是为了确定保存小型、中型和大型项目日益增加的基线数量的影响。

在我们的测试中,随着项目中所保存的基线数量的增加,文件大小和虚拟内存大致呈线性增长。保存基线所需的时间随着项目的增大而增加。在达到最大基线数量前,完成小型和中型项目的文件 I/O 操作所需的时间不会增加。对于大型项目,在添加第八个基线后完成文件 I/O 操作所需的时间显著增加。

Project Server 2007 输入和输出图表

项目深度和广度限制

执行测试的目的是确定在主项目中插入子项目时对性能所产生的影响。执行了两种不同类型的测试:

  • 深度测试(递归)

  • 广度测试(非递归)

深度测试

深度测试主要是指以递归方式插入子项目。例如,Proj01 插入到 Proj02 中。然后此链插入到 Proj03 中。随后此链插入到 Proj04 中,依此类推。链中的各个项目是相同的,测试的目的是弄清楚每个项目(小、中、大)能够以递归方式插入多少次,以及各个性能度量标准如何随之变化。

在递归插入测试中,实际上所有重要参数的大小呈线性增加。深度方面的限制因素是内存使用量,例如,在 16 级,大型项目(包含约 10,000 个任务)接近 32 位虚拟内存限制。然而,即使在此示例中,保存操作的速度仍然非常快。其他操作(例如,关闭并重新打开主项目、插入新图层、强制执行重新计算)都非常费时。64 位服务器平台可显著增加所能插入的项目的数量,但是要求此深度的项目并不多见。

下图显示了随着递归插入项目的数量增加,完成文件 I/O 操作所需时间如何增加。请注意,大型项目不能体现此情况,而中型项目的性能在进行少数几次的递归后便会显著下降。

Proj Server 软件边界图形

广度测试

广度测试主要是指在同一大纲级别(即,非递归)将子项目插入单个主项目。

每个主要参数的大小随项目广度的拓宽呈线性增加。在插入约 35 个中型非递归的文件时,内存使用量将成为一个瓶颈,在 20 个项目的广度下,完成保存和打开操作所需的时间约为 400 秒。如同使用递归插入一样,使用 64 位平台将明显增加可插入的项目数量,但需要此广度的项目并不多见。

下图展示了完成中型项目的文件 I/O 操作所需的时间如何随非递归插入的项目数的增加而增加。

I/O 操作的时间与项目对比的图形

Project Server 性能和网络延迟

Office Project Server 2007 可在高网络延迟的环境中顺利执行。对 Office Project Server 2007 所做的设计更改在通常的单用户文件 I/O 方案(尤其是高延迟广域网 (WAN) 环境)中会带来明显的好处。在高延迟(50 分钟)广域网中通过 Project Server 2003 打开大文件所需的时间可能长达 45 分钟,但在 Office Project Server 2007 上测试同一操作所需的时间不足一分钟。工作组生成器在 Office Project Professional 2007 中所展示的性能提升与在广域网环境中类似。尽管使用低延迟网络连接具有明显的好处,但与以前版本的性能相比,Office Project Server 2007 在 WAN 中的性能已经有了显著的提高。

尽管 Office Project Server 2007 的初始启动性能低于 Project Server 2003 的性能,但它在随后启动中的性能会显著提高并且优于其前一版本。

可接受性能的指导标准

可伸缩性直接影响容量。此部分介绍可撰写 Microsoft Office Enterprise Project Management (EPM) Solution 的对象并为每种对象类型提供可接受性能的指导标准。

如果您的解决方案计划超出了一个或多个对象的推荐指导标准限制,请执行以下一项或多项操作:

  • 评估解决方案以确保其他方面进行了相应补偿。

  • 在构建和部署解决方案时标记这些方面以进行测试和监控。

  • 重新设计解决方案以确保不会超出容量指导标准限制。

下表列出了将应用限制的 Office Project Server 2007 对象,并包括可接受性能 的推荐指导标准。可接受性能表示系统经测试证明能够支持一定数量的对象,但是如果超出这个数量,就会造成性能的降低。星号 (*) 表示硬性限制;无星号表示经过测试的限制或所支持的限制。

对象 可接受性能的指导标准 说明

每个服务器场中的资源

40,000

这是经过测试的限制。

每个项目所包含的基线

建议 7 个

最多 11 个*

测试显示当生成 7 个以上的基线时,对大项目文件执行某些操作,性能会降低。有关详细信息,请参阅本文前面部分介绍的“基线对性能的影响”。

插入项目的深度(递归)

16

此级别的性能降低非常显著。

插入项目的广度(非递归)

20

此级别的性能降低非常显著。

每个项目所包含的任务

5,000

这是经过测试的限制。

任务时长(以月计)

300

当工时分布应用于任务时,发布项目所需时间取决于任务时长。此影响可能相当大,尤其是在 EPM 解决方案 用于创建项目周期为数年的项目时。

这是经过测试的限制。

每个任务的工作分配

16,000

这是经过测试的限制。尽管您可以为每个任务添加 16,000 多个工作分配,但是向已经包含 16,000 个工作分配的任务添加工作分配,需要花费 7 秒多的时间。

本地自定义公式域

10-30

每个任务所允许的本地自定义公式域的数量取决于自定义域的类型。下面的列表介绍自定义域的类型及其限制:

  • 任务文本:30

  • 任务成本:10

  • 任务日期/开始/完成:10

  • 任务工期:10

  • 任务标记:20

  • 任务数:20

  • 任务大纲代码:10

  • 资源文本:30

  • 资源成本:10

  • 资源日期/开始/完成:10

  • 资源工期:10

  • 资源标记:20

  • 资源数字:20

  • 资源大纲代码:10

每个服务器的企业自字义公式域

32,000

此为理论上的限制,该限制适用于可应用域的各个实体类型。但是,尚未对约 1,000 个以上的企业自定义域执行性能测试。

工作组生成器资源限制

10,000 个资源

显示“工作组生成器”对话框所需的时间少于 5 秒(即使是服务器上存在 10,000 个资源)。虽然 10,000 个资源是经过测试的限制,但是如果随后增加显示对话框所需的时间是可以接收的,则工作组生成器可用于更多资源。

另请参阅

概念

在 Project Server 2007 中管理 Active Directory 同步