Monitoring for Growth

No matter how well you estimate your future needs, they are still estimates, subject to the reality that is the business environment. Microsoft's EPM solution is extremely scalable. There are always ways to address performance issues. Putting in place proactive monitoring allows an organization to respond when a performance degradation trend is identified, before the user community is severely impacted.

A solid monitoring program consists of two components:

• Tracking the changes made to the system

• Tracking the performance of the system

Each of these components is critical. Without tracking changes to the system, performance degradation can be assumed to be user or data complexity based when in fact it is not. Incorrect actions may be taken to remedy the degradation and time and money inefficiently spent.

In support of the change control aspect, the following system changes should be logged when any change is made:

• Any system updates via Service Packs (OS or application)

• Changes in Project Server availability and OLAP window data range sizes

• Additions/modifications to the Project Server Category/Group model

• Additions of new Enterprise Custom Fields (Task, Project, or Resource) or to the formulas used by them

• Additions/modifications of any customizations (triggers/stored procedures/ASP pages)

• Additions or changes to other applications sharing the Project Serverrelated servers

• Network changes between clients/servers and/or servers/servers

• Client changes (upgraded hardware/OS/application suites)

Tracking the performance of the system is currently a manual chore. At least check the following monthly (the preference would be weekly):

• The number of active projects in the database

• The total number of projects in the database

• The number of resources in the database

• The average number of assignments in the database

• The network latency (done via a command shell ping) between remote clients and the SQL Server

• The time it takes Project Professional to open the chosen test project during a low-usage time

• The time it takes Project Professional to open the chosen test project during a peak usage time (as defined by the peak usage scenarios for your organizationpossibly a Friday afternoon time entry or a Monday morning project progression by project managers)

• The time it takes to display the PWA Detail Project view for the chosen test project

• The time it takes for the OLAP cube to build

Routinely logging or tracking the preceding items is drudgery, but the return can be enormous. Having and tracking the preceding information allows an organization to see trends in performance and understand and identify bottlenecks earlier. This information can then be used to make adjustments in architecture or to spot business or usage practices that are not as expected and either address the practices directly or adjust the capacity planning to account for them.

TIP

Routinely collecting performance information can be done by soliciting the user community to log performance by performing operations on a designated test project or test view during peak usage times. It is also worthwhile to look at the SmokeTest utility (a free download from Microsoft) to automate this activity. The SmokeTest utility can be found at

http://www.microsoft.com/downloads/details.aspx?FamilyID=68fd51ba-2037-4c75-a529-1da948c24c0c&DisplayLang=en