Export (0) Print
Expand All

Plan for software boundaries (Project Server)

Office 2007

Updated: May 7, 2009

 

Topic Last Modified: 2009-04-27

In this article:

This article provides information to help you understand the tested performance and capacity limits of Microsoft Office Project Server 2007, provides information about the test environment and test results, and offers guidelines for acceptable performance. Use the information in this article to determine whether your planned deployment falls within acceptable performance and capacity limits.

The test results and guidelines provided in this article apply to a single installation of Office Project Server 2007. Adding server computers to the installation does not increase the capacity limits of the site objects that are listed in the table in the Guidelines for acceptable performance section. On the other hand, adding server computers does increase the throughput of a server farm, which might be necessary to achieve acceptable performance with large numbers of objects. In some cases, the requirements for high numbers of objects within a solution might require the use of more than one server farm.

In this article, the guidelines are determined by performance. In other words, you can exceed the guidelines provided, but as you increase the scale, you may experience reduced performance.

Note that there are many factors that can affect performance in a given environment, and each of these factors can affect performance in different areas. Some of the test results and recommendations in this article might be related to features or user operations that do not exist in your environment, and therefore do not apply to your solution. Only thorough testing can provide you with exact data related to your own environment.

Because Office Project Server 2007 is based on Windows SharePoint Services 3.0, most of the factors that affect the performance and capacity of Windows SharePoint Services 3.0 will also affect Office Project Server 2007. For more information about capacity and performance planning for Windows SharePoint Services 3.0, see Plan for performance and capacity (Windows SharePoint Services).

To provide a high level of test-result detail, several farm configurations were used for testing, including one server computer performing Web server and application server roles, one or two client computers, and a single database server computer running Microsoft SQL Server 2000 database software. Some testing was performed with a separate application server computer. A dedicated domain controller computer was also used in the test lab. All server computers were 32-bit.

The following table lists the specifications of the computers performing each role in the test environment.

 

Computer role Specifications

Web server and application server

4 AMD Opteron 2.2 gigahertz (GHz) processors, 2 gigabytes (GB) RAM

Application server

4 AMD Opteron 2.2 GHz processors, 2 GB RAM

Database server

4 Intel Xeon 1.5 GHz processors, 4 GB RAM

Client

1 Pentium D 3 GHz processor, 2 GB RAM

Domain controller

2 Pentium III 1 GHz processors, 512 megabytes (MB) RAM

NoteNote:
Based on CPU and memory usage during testing, the relatively low specifications of the domain controller did not present a significant bottleneck.

A 100 megabit Ethernet network was used between the farm computers.

The following charts, graphs, and tables show how the test environment performed given server configuration, user operations, and load conditions. Results provided apply to all similar Office Project Server 2007 environments.

NoteNote:
Additional configurations will be tested in the future. Test results will be published as they become available.

Performance metrics for different operations depend on such factors as how large the project files are, how many baselines exist in a given project, and the throughput of the farm. For example, a small project file — smaller than 1 megabyte (MB) — might require less than one second to save, whereas a 50 MB project file will likely require more than one minute to save, depending on your farm configuration and network latency.

The following table describes the three different sizes of project files that were used in testing.

 

Size File size (MB) Number of tasks Number of resources Number of assignments

Small

0.896

10

10

10

Medium

2.03

1,420

94

1,486 assignments on real resources, 380 unassigned

Large

8.139

10,422

2

5 assignments on real resources, 7,693 unassigned

This test was conducted to measure how the performance of Active Directory directory service synchronization degrades as the number of resources increases.

Windows SharePoint Services 3.0 provides the underlying security and user management architecture for Office Project Server 2007. To manage domain users as resources in Office Project Server 2007, you must synchronize Active Directory for the domain with Windows SharePoint Services 3.0 on one of the servers in your farm.

Active Directory synchronization does not show linear complexity with regard to the number of resources imported. Complexity is roughly quadratic, and synchronization between Windows SharePoint Services 3.0 and Active Directory exemplifies this. Based on test results, we can estimate that Windows SharePoint Services 3.0 synchronization for a 20,000-seat organization would require approximately 28 hours on the test hardware. Windows SharePoint Services 3.0 synchronization for a 40,000-seat organization would complete in approximately 109 hours (4.6 days). Note that these estimates are based on the hardware and network specifications used for this testing.

In general, doubling the size of the resource pool requires nearly four times the amount of time required for Active Directory synchronization for a given farm configuration and network bandwidth. Regardless of hardware, for a very large organization, the first Active Directory synchronization job will likely run for more than one day.

The following graph shows the time required to complete Active Directory synchronization as the number of resources increases.

Active Directory synchronization graph

For more information about synchronization between Active Directory and Office Project Server 2007, see Manage Active Directory synchronization in Project Server 2007.

Office Project Server 2007 allows as many as 11 baselines to be saved within a given project. As the number of baselines in a project increases, performance is affected in a number of ways. Testing was conducted to determine the effect of saving increasing numbers of baselines for small, medium, and large projects.

In our testing, file sizes and virtual memory increases appear to be roughly linear with regard to the number of saved baselines in a project. The amount of time required to save a baseline increases with the size of the project. The time required for file I/O operations did not increase for small and medium-sized projects up to the maximum number of baselines. For large projects, the time required for file I/O operations increased significantly after an eighth baseline was added.

Project Server 2007 input and ouput chart

Tests were conducted to determine how performance is affected when subprojects are inserted into master projects. Two different types of tests were performed:

  • Depth testing (recursive)

  • Breadth testing (non-recursive)

Depth testing involved recursively inserting subprojects. For example, Proj01 was inserted into Proj02. This chain was then inserted into Proj03. This chain was inserted into Proj04, and so on. Each project in the chain was identical, and the goal of the testing was to see how many times each project (small, medium, large) could be recursively inserted, and how various performance metrics responded.

In testing of recursive insertion, virtually all significant parameters scaled linearly. The limiting factor on depth is memory usage — for example, at 16 levels, the large project, which contained approximately 10,000 tasks, approached 32-bit virtual memory limits. Even in this example, however, save operations executed very quickly. Other operations, such as closing and then reopening the master project, inserting new layers, and forcing recalculation, were significantly more time-consuming. A 64-bit server platform would significantly increase the number of projects that you could insert, but projects that would require such depth are not common.

The following graph shows how the time required to complete file I/O operations increases when the number of recursively inserted projects increases. Note that large projects are not represented, as the performance of medium-sized projects showed significant degradation after a fairly small number of recursions.

Proj Server software boundaries graph

Breadth testing involved inserting subprojects at the same outline level (that is, non-recursively) into a single master project.

Every major parameter scaled linearly with project breadth. Memory usage becomes a bottleneck after approximately 35 medium-sized non-recursively inserted files, and the time required to complete save and open operations is approximately 400 seconds at a breadth of 20 projects. As with recursive insertion, the use of a 64-bit platform would significantly increase the number of projects that could be inserted, but projects requiring such breadth are not common.

The following graph shows how the time required to complete file I/O operations increases for medium-sized projects when the number of non-recursively inserted projects increases.

Graph of time for I/O operations versus projects

Office Project Server 2007 performs well in environments that have high network latency. The design changes made for Office Project Server 2007 provide significant benefits in common single-user file I/O scenarios, especially in high-latency wide-area network (WAN) environments. Opening a large file across a high-latency (50 ms) WAN in Project Server 2003 could take as long as 45 minutes, but the same operation tested on Office Project Server 2007 required less than one minute. Team Builder in Office Project Professional 2007 shows similar performance gains in WAN environments. Although there are clear benefits to using a low-latency network connection, the performance of Office Project Server 2007 over WANs has improved dramatically from the performance of previous versions.

Although initial startup performance of Office Project Server 2007 lags behind that of Project Server 2003, it performs significantly better on subsequent starts and outperforms its predecessor.

Capacity is directly affected by scalability. This section describes the objects that can compose a Microsoft Office Enterprise Project Management (EPM) Solution and provides guidelines for acceptable performance for each type of object.

If your solution plans exceed the recommended guidelines for one or more objects, perform one or more of the following actions:

  • Evaluate the solution to ensure that compensations are made in other areas.

  • Flag these areas for testing and monitoring as you build and deploy your solution.

  • Re-design the solution to ensure that you do not exceed capacity guidelines.

The following table lists the Office Project Server 2007 objects to which limits apply, and includes recommended guidelines for acceptable performance. Acceptable performance means that the system as tested can support that number of objects, but that the number cannot be exceeded without some performance degradation. An asterisk (*) indicates a hard limit; no asterisk indicates a tested or supported limit.

 

Object Guidelines for acceptable performance Notes

Resources per farm

40,000

This is the tested limit.

Baselines per project

7 recommended

11 maximum*

Testing indicated performance degradation for certain operations on large project files when more than seven baselines were generated. For more information, see "The effect of baselines on performance" earlier in this article.

Depth of inserted projects (recursive)

16

Performance degradation at this level is significant.

Breadth of inserted projects (non-recursive)

20

Performance degradation at this level is significant.

Tasks per project

5,000

This is the tested limit.

Task length in months

300

The amount of time for a project to publish is dependent on task length when work contours are applied to tasks. This impact can be significant, especially if EPM Solution is used to create projects that span several years.

This is the tested limit.

Assignments per task

16,000

This is the tested limit. Although you can add more than 16,000 assignments per task, it took over seven seconds to add an assignment to a task that already contained 16,000 assignments.

Local custom formula fields

10-30

The number of local custom formula fields allowed per task depends on the type of custom field. The following list shows the types of custom fields and their limits:

  • Task Text: 30

  • Task Cost: 10

  • Task Date/Start/Finish: 10

  • Task Duration: 10

  • Task Flag: 20

  • Task Number: 20

  • Task Outline Code: 10

  • Resource Text: 30

  • Resource Cost: 10

  • Resource Date/Start/Finish: 10

  • Resource Duration: 10

  • Resource Flag: 20

  • Resource Number: 20

  • Resource Outline Code: 10

Enterprise custom formula fields per server

32,000

This is a theoretical limit, and the limit applies to each entity type to which you can apply a field. However, performance testing has not been conducted with more than approximately 1,000 enterprise custom fields.

Team Builder resource limits

10,000 resources

The Team Builder dialog box takes less than five seconds to display even when 10,000 resources are present on the server. Although 10,000 resources is the tested limit, Team Builder can be used with more resources if the subsequent increase in time required for the dialog box to appear is acceptable.

This topic is included in the following downloadable book for easier reading and printing:

See the full list of available books at Downloadable content for Project Server 2007.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft