• Article

Plan a Project Server 2010 performance test lab

 

Applies to: Project Server 2010

Topic Last Modified: 2011-03-11

Planning is the first and most important phase of every complex task, and performance testing is no exception to this rule. For specific information about how to plan your Microsoft Project Server 2010 installation, see Planning and architecture for Project Server 2010.

Before setting up the environment and running tests, you should thoroughly plan for all the aspects of what you will do. The following table summarizes some key points that you have to plan for.

Area Description

Hardware

Your lab configuration should be as close as possible to your existing or target production environment. For future reference, ensure that you keep track of the details of your hardware configuration before completing the lab.

Software

Plan for installing the latest fixes available for every software component in your lab. If you plan to run the lab for a long time (one month or more), you should also plan to update the systems when it is necessary with the latest security fixes. If you do not strictly have to change the software configuration of your systems, you should avoid changes during the lab timeframe, in order to maintain data comparability across different test runs performed at different times.

Storage

Your lab should have enough storage space to store:

  • Live data

    • Project Server databases

    • SharePoint Server databases

  • Backups

    • One backup set right after the lab setup

    • One backup set of Project Server and relevant SharePoint Server databases for every different data profile that you have to use

  • Test results

    The storage size required for every test run depends on the set of data that you collect, the sampling rate, and the test length

Network

Your lab environment should be put on an isolated network, in order to minimize the effect of extraneous network activities on your tests. One computer in the lab is usually configured as a bridge for remote access to the lab from the corporate network.

Directory Services

Because you have to simulate users who are accessing your lab environment, and you have to know the passwords for each simulated user, you must plan for the Directory Services to be used. You should plan for a dedicated organizational unit (OU) in an existing Active Directory directory service domain for managing the test user accounts, or for a dedicated Active Directory domain for your lab environment.

Test scenarios

Based on your overall goals for the performance lab, your test scenarios must be planned carefully. Consider the following elements for every test scenario:

  • Operations to be simulated (either a single operation or a mixed set of operations with different percentages)

  • Users and roles that have to be simulated for every operation (that is, how many users for every role involved, and so on)

  • Data profile to be created at the beginning of the test (that is, how many projects, tasks per project, assignments per resource, assignments per project, and so on)

  • Test duration and load pattern (that is, warm-up time, step load, and so on)

  • Data to be collected (that is, which counters from which servers, sampling rate, and so on)

  • Acceptance criteria and thresholds (that is, less than x% errors, average CPU usage < 60%, and so on)

Data profiles

Putting together all the test scenarios that you will perform, plan for your overall data population strategy by identifying the minimum number of data profiles that you will need for your tests. Data profiles typically include the following elements:

  • Users

    • User accounts

    • Resource Breakdown Structure (RBS)

    • Enterprise Resource Pool

    • Project managers and other roles

    • Security (authentication mode, groups, categories)

  • Enterprise Custom Fields

  • Projects

    • Tasks

    • Task dependencies

    • Team

    • Assignments

You should plan for an appropriate naming convention for all the test entities (users, projects, tasks, and so on).

Please send any comments, questions, or concerns about the documentation to epmdocfeedback@microsoft.com.