Export (0) Print
Expand All

Microsoft Project Server 2002 Configuration Guidelines

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
Updated : August 27, 2002

By Bob Vogt ,Neicole M. Crepeau ,Microsoft Corporation

Applies to:
Microsoft Project Server 2002

Summary This paper describes options for determining the right configuration for your Microsoft Project Server installation, thus optimizing Microsoft Project Server scalability and performance in your organization.

On This Page

Introduction
Elements of Scalability and Performance
Determining Scalability and Performance Requirements
A Hardware Configuration Case Study
Additional Deployment Considerations
Conclusion

Introduction

Scalability and performance can be defined as the ability of a system to grow and respond to all users in a timely manner. How do you guarantee that a Microsoft® Project Server installation is adequately scalable and performs optimally? Unfortunately, no reference system or single configuration will meet all customers' requirements. However, there are many options for configuring the system. This paper lays out some of the options for determining the right configuration to optimize Microsoft Project Server scalability and performance in your organization.

This paper includes the following sections:

  • Elements of Scalability and Performance

    Describes the available technologies for increasing the scalability and performance of a system.

  • Determining Scalability and Performance Requirements

    Outlines the criteria for determining scalability and performance requirements of Microsoft Project Server. You will need to understand your requirements to select the appropriate technology options.

  • A Hardware Configuration Case Study

    Describes a study performed to test the threshold for hardware upgrades in a two-machine and three-machine configuration.

  • Additional Deployment Considerations

    Briefly describes the application of specific technologies for increasing the scalability and performance of your Microsoft Project Server installation.

Elements of Scalability and Performance

This section describes some of the key elements that affect scalability and performance.

Hardware Configuration

The Microsoft Project Server system requirements are documented at the Microsoft Project Product Site as well as in the file Readme.htm on the installation CD. Microsoft Project Server can be configured to run on hardware ranging from a single, powerful, workstation-class desktop computer to an array of data-center-class server computers. The following list shows some of the possible Microsoft Project Server hardware configurations:

  • One computer

    Microsoft Internet Information Server (IIS) and Microsoft Desktop Engine (MSDE). This configuration is appropriate for evaluation.

  • Two computers

    IIS + Microsoft SQL Server™ (see figure 1 below). This configuration is a minimal configuration suitable for departmental deployments.

  • Five computers

    IIS + Application Server + Microsoft SQL Server + Microsoft SQL Server Analysis Services + SharePoint™ Team Services from Microsoft (see figure 2 below). This configuration is suitable for larger departmental or small company deployments.

  • N computers

    This configuration is suitable for large-scale deployments (see figure 3 below).

This list represents some of the simpler combinations available to you. As scalability and performance requirements increase, you can use additional computers to further distribute the workload. Ways to distribute the workload are discussed in further detail in the following sections.

Cc751001.psvconfg01(en-us,TechNet.10).gif

Figure 1: Two machine configuration

Figure 2: Five machine configuration

Figure 2: Five machine configuration

Cc751001.psvconfg03(en-us,TechNet.10).gif

Figure 3: Large scale deployment

Load Balancing

The number of users that Microsoft Project Server can handle on a single computer is limited by the number and speed of the processors, the amount of memory, and other factors, such as bus speed, I/O speed, and L2 cache. One way to improve scalability and performance is to upgrade the computer where Microsoft Project Server is installed. However, one extremely powerful computer can be more expensive than several less powerful computers, and also may not be as scalable or perform as well. On the other hand, total cost of ownership (TCO) may be lower for a single, powerful machine than for several less powerful machines.

Microsoft Project Server is designed to be deployed across several IIS servers for additional scalability and performance. In the second, third, and fourth examples in the previous section, Microsoft Project Server was deployed across different machines such that the application runs on a computer with IIS, the database resides on a computer with Microsoft SQL Server, and SharePoint Team Services and SQL Server Analysis Services are installed on two other computers. While this does distribute the total workload, running the application itself on a single computer can still cause a bottleneck. To scale out even further, the application can be deployed across multiple computers running IIS. It should be noted that there can be at most one computer running each of SQL Server and SQL Server Analysis Services for a given Microsoft Project Server installation (though SQL Server may be clustered for failover). See figures 1, 2, and 3 above.

Determining Scalability and Performance Requirements

This section describes criteria for determining the scalability and performance requirements of Microsoft Project Server. These criteria are the environment where the system will be hosted and the way that you will use Microsoft Project Server. You need to analyze your organization's needs according to these criteria.

Hosting Environment

The scalability requirements for a department installation to serve 20 users are vastly different from that of an extranet installation intended to serve thousands of users. The first step to determining scalability and performance requirements is to understand the hosting environment. Specifically, you should consider the following factors:

  • The number of concurrent users

    In determining application deployment and hardware configuration, consider not just the total number of users, but the maximum number of concurrent users. Further, it's a good idea to categorize users roughly into project managers, team members, and executive stakeholders. Project managers put the most stress on the Microsoft Project Server machine, but there are usually far more team members than project managers.

  • The features to be implemented

    Your organization may not use all of the features of Microsoft Project Server. The features you use affect the scalability and performance requirements. For instance, if Microsoft Project Server Portfolio Analyzer won't be used, the installation won't require SQL Server Analysis Services, and the computer where the application is installed will be required to perform fewer types of transactions. The more features implemented, the greater the load on the computer or computers running the application.

  • How the application will be accessed

    If the application will be accessed from the Internet through a firewall, the security requirements will be more rigorous than a departmental system run from a desktop-class computer. Secure Sockets Layer (SSL) adds significant stress to application performance.

Usage Profile

The core function of Microsoft Project Server is to provide distributed project management capabilities. These capabilities include resource management, project tracking, status reporting, and project reporting. Beyond that, additional features that support project collaboration, project portfolio reporting (reporting across projects), and project modeling can be used. Each of these features has an impact on the scalability and performance of the installation.

  • Project tracking

    This core functionality is a standard part of Microsoft Project Server and is always installed. Project tracking consists of assignment posting, timesheets, status reporting, and project views.

  • Collaboration

    This feature adds document management and issue tracking, and requires SharePoint Team Services. This feature set adds some additional load on the Microsoft Project Server machine, though most of the work is performed by SharePoint Team Services.

  • Enterprise project management

    This feature adds project check-in and check-out, an enterprise resource pool, automated resource assignment and substitution, and portfolio modeling. This feature set adds significant load on the Microsoft Project Server machines.

  • Portfolio reporting

    This feature adds data warehouse reporting, and requires SQL Server Analysis Services. This feature set adds additional load over and above that which is added by using enterprise project management.

The following table illustrates a typical use of Microsoft Project Server. You may want to create a similar table to describe usage in your organization.

Role

Usage(min./period)

Functions

Average concurrency

Project manager (PM)

60/day

Publish schedules

Total PMs/7

 

 

Accept team member (TM) updates

 

 

 

Project Center Views

 

 

 

Portfolio Modeler

 

 

 

Upload documents to project team site

 

 

 

Add issues to log

 

TM

15/week

Timesheet*

Total TMs/8

 

20/day

Accept assignments

Total TMs/21

 

 

Open issues/docs

 

Resource manager

30/day

Accept/delegate assignments

Total TMs/14

 

 

Resource Center views

 

 

 

Portfolio Analyzer

 

Executive

15/day

Project Center views

Total Executives/28

 

 

Resource Center views

 

 

 

Portfolio Analyzer

 

 

 

Portfolio Analyzer

 

Administrator

120/day

Add users

Total Administrator/3.5

 

 

Create/edit views

 

The average concurrency for all functions except timesheet were derived by assuming a seven-hour actual work day

*For testing, weekly timesheet entry should be assumed to be a separate process taking place over a short period of time (two hours total, usually concentrated on Friday afternoon or Monday morning). During this period of time, most other roles will not be using the system.

A Hardware Configuration Case Study

A case study was performed to determine the thresholds at which typical hardware configurations should be upgraded based on a typical usage pattern and data profile. Because every installation's parameters will differ in some way, this case study should be used as a guide rather than a formula for determining the best configuration for your installation.

Testing Methodology

The test was conducted in two phases:

  • A continuous, multi-user workload was applied against a two-machine configuration (see figure 1 above). Performance Monitor data and automated test script response times were captured during the test run and analyzed to determine the point at which this configuration could benefit from off-loading the views processing work.

  • Views processing was then off-loaded to a third server machine and a similar workload was applied against this configuration to determine the point at which this configuration could benefit from deploying additional IIS servers running Microsoft Project Server.

Scenarios Tested

The workload consisted of the core distributed enterprise project management scenarios involving the following users and tasks:

  • Project Manager

    • Open a project from a Microsoft Project file

    • Build a team from Enterprise Resource Pool

    • Assign tasks

    • Save the project to the Enterprise Repository

    • Save and close the project with full publish

  • Team Member

    • Navigate to the site

    • Login as a Microsoft Project Server user

    • View assigned tasks

    • Create new tasks

    • Delegate one task

    • Submit one actual (% complete)

    • Submit one actual (actual work)

    • Submit one actual (actual hours)

    • Submit an update to non-work time

    • Send an un-requested status report

    • Send a requested status report

    • Delete a status report

    • Set and save notification options

    • View a previously sent status report

    • Send an update for all tasks (% complete)

    • Reject a task

    • Log out

The tests were conducted with a 1-to-8 ratio of project managers to team members. (Note: Research has indicated an average of 1-to-10 project managers to team members.)

Data Profile

  • A mix of 880 small, average and large projects

    • Small: 100 tasks, 10 resources, 100 assignments

    • Average: 500 tasks, 50 resources, 500 assignments

    • Large: 1500 tasks, 150 resources, 1500 assignments

  • Over 4000 enterprise resources with assignments across projects

Hardware Profile

Tests were conducted on hardware with the following characteristics:

  • Single IIS Server (Microsoft Project Server)

    2 x 2.2GHz P4 Processors
    1GB Ram
    40GB hard drive

  • Single Application Server (Views Processor)

    2 x 1GHz P3 Processors
    512MB Ram
    40GB hard drive

  • Single Database Server

    4 x 700MHz P3 Processors
    2GB Ram
    4 x 18GB Hard drives with hardware RAID5 configuration

Test Results

These are the thresholds for the hardware, workload and dataset described above:

  • The minimal two-machine configuration optimally supported up to approximately 5000 total users.

  • The three-machine configuration optimally supported up to approximately 6000 users.

The total number of users was calculated from the number of concurrent users by role. (See the earlier section titled "Usage Profile.") Deploying Microsoft Project Server across multiple IIS servers will increase the scalability.

Variables that could affect these numbers in a specific environment include:

  • Higher frequency of project publish operations which will be more common in environments with lots of smaller projects

  • Additional workload on the server due to STS subweb creation, OLAP cube generation and/or portfolio modeling

  • Extensions to Microsoft Project Server functionality or sharing machine resources with other applications

  • Smaller hardware, network bandwidth and other environmental considerations

Recommendations

  • If the number of users and the dataset size is expected to grow beyond the initial implementation, the system should be deployed in a distributed configuration initially. As load increases, you can deploy additional IIS servers with Microsoft Project Server with little or no disruption to system availability.

  • The Microsoft Project Server database should be deployed on the highest-capacity (specifically CPU and memory) SQL Server machine possible to accommodate system growth, particularly since the database server cannot be scaled out like the Microsoft Project Server machines can. Otherwise, as more Microsoft Project Server machines are deployed, SQL Server performance might not be able to keep up with the middle tier servers.

Additional Deployment Considerations

Based on the analysis of your organization's requirements, you can use the various technologies available to configure your Microsoft Project Server installation. This section describes some of the ways you might use specific technologies to configure your installation.

Secure Access

Access to Microsoft Project Server data and its functionality is secured primarily through application security, although SharePoint Team Services and SQL Server Analysis Services require Microsoft Windows® security. To secure access from the Internet, it is highly recommended that you implement SSL. This adds additional overhead, however, and can significantly affect performance of the application. You can mitigate this impact by implementing hardware encryption/decryption either using an onboard card or in the front-end router that controls Internet ingress and egress, if a card or router is installed.

Load Balancing

Depending on the services you use, you can distribute the load among computers to significantly enhance system performance.

  • Microsoft Project Server Session Manager Service

    You will probably want to deploy Microsoft Project Server across multiple application servers. In order to do so, session management must be removed from the IIS server and deployed on its own application server. This allows users to be directed to any one of a farm of IIS servers running Microsoft Project Server. See the "Microsoft Project Server Installation Guide" on the installation CD for more information.

  • Microsoft Project Server View Manager Service

    When projects are published to Microsoft Project Server, a copy of the project is uploaded and used to create project view data. This process is expensive because it must open the project in the Microsoft Project OLE DB provider to save data to build views from. You can offload this service to improve the scalability and performance of a single IIS server or a farm of IIS servers. See the "Microsoft Project Server Installation Guide" on the installation CD for more information.

  • Microsoft Project Server Portfolio Analyzer Service

    While it is possible to install SQL Server Analysis Services on the same computer with Microsoft SQL Server (and all of these on the same computer as the application), significant performance gains can be realized by installing SQL Server Analysis Services on its own computer.

  • Documents and Issue Tracking

    Again, while it is possible to install SharePoint Team Services on the same computer with the application, significant performance gains can be realized by installing it on its own computer.

Database Optimization

The Microsoft Project Server database is configured with the optimal indexes to support the queries executed against the tables. It is recommended that the indexes not be altered. However, database administrators can configure the physical placement of database files for optimal performance and administration. One common practice is to separate indexes from tables, allocating one or more striped disk drives for each. Normal monitoring and maintenance will keep the database performing optimally and allow it to be quickly recovered in the case of a hardware failure.

Note: For evaluation or very small departmental or workgroup installations, MSDE is an appropriate database server. The default installation of Microsoft Project Server will install MSDE on the IIS computer with the application.

RAID, Files, and File Groups

Depending on site-specific database implementation standards, placing data, index, and log files on specific files and file groups can improve performance. Additionally, RAID can improve both performance and reliability.

Regular Maintenance

One of the most important factors in maintaining performance and reliability is regular database maintenance including:

  • Backing up data regularly.

  • Copying log backups redundantly and/or to separate disks.

  • Reorganizing indexes periodically.

  • Running a database consistency checker utility (DBCC) to ensure the integrity of the file structures.

Hardware Configuration

For installations of more than 1,000 users or installations that are business critical, multiple IIS servers should be deployed to optimize availability and reliability. Such configurations will require a high-end database server computer.

The actual range of users that determine the configuration will vary based on the ratio of usage categories and the class of servers selected for the application tier. (See the previous section titled "Usage Profile.")

Conclusion

Analysis and planning are the keys to performance and scalability. To adequately plan, the requirements must be known before Microsoft Project Server is installed. Consider the following:

  • Number of concurrent users

  • Usage patterns of those users

  • Features to be used

  • Security access requirements

After installation, regular monitoring and maintenance should keep Microsoft Project Server running at peak performance.

Bob Vogt is a program manager in the Microsoft Project Business Unit and has been at Microsoft for six years.

Neicole M. Crepeau is a technical writer in the Business Tools Division User Experience group and has been at Microsoft for nine years.

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