Project Server 2007 Performance

[irish_archer68]

Hello and thanks for reading.
I have a Produciton Environment consisting of 2 virtualized servers
with teh follwoing specs:
Win Server 2008 OS (64 bit)
Project Server 2007 SP2
SQL Server 2005 SP1
WSS 3.0

Project server runs on the App Server and SQL Server on a dedicated
virtual server.

Each virtual server has 4-Six Core processors at 2.5 GHZ
!0 GB Ram
50 GB of storage space.

I have several schedules with varying number of tasks. Schedules of
~1000 tasks save in 2-3 minutes. One schedule with 2500 tasks that
takes almost 90 minutes.
I tried removing "past data" in the schedules by rebuilding the
schedule so there are truely only 2500 tasks and not the 6000 + that
were savd with the original file. The rebuilt file still takes 25
minutes to save.
I have been working with the DBAs to tune SQL server to ensure that is
not an issue. But in analyzing the server, the CPUs and Disk I/O are
not even hitting 50 %. Am I hitting some mythical SQL threshold with
2500 tasks?

PLEASE advise.

 

[Carl Dalton]

Things that can impact performance:
- Timephased edits of Work - if you manually edit work (via "usage"
views) or have actual work submitted from users via PWA, on very long
tasks, this can cause exponential slowdown.
- LArge numbers of resources on tasks where the above exists
- Long task/assignments where any of the above exist
- Multiple Baselines as above

Any mis'n'match of any of the above can dramatically impact
performance from the client side.

E.g, A project that has 500 tasks, each one being approx 2month long
with multiple resources (10+) on each task, used for time recording
capture.

There are some potential issues with bad data in plans. To rule out
data issues in the plan itself, try cleaning it
- Take the plan and save it locally
- Save the local plan as XML
- Open this and save as a new MPP
- Save this to the server
- Compare performance

Between these two activities you should find out where the issue(s)
are.

Notes:
is the performance the SAVE job, the PUBLISH job, or the transfer of
data thats performed prior to save (where the client locks briefly)
you said Project Server SP2 and WSS. is WSS SP2 too (as it should be)
What version of the project client are you using? min SP2
suggest upgrade to a recent CU across server and client (i think Oct
CU for Project Server and Project is stable and tested)
On the SQL side, you could run the SP_UPDATESTATS on each SQL DB to
see if there are reindexing activities that are updated on the tables
Has this been confirmed from other client machines (just to rule out a
client performance issue)


good luck

Carl@EPM

 

[irish_archer68]

Things that can impact performance:
- Timephased edits of Work - if you manually edit work (via "usage"
views) or have actual work submitted from users via PWA, on very long
tasks, this can cause exponential slowdown.
- LArge numbers of resources on tasks where the above exists
- Long task/assignments where any of the above exist
- Multiple Baselines as above

Any mis'n'match of any of the above can dramatically impact
performance from the client side.

E.g,  A project that has 500 tasks, each one being approx 2month long
with multiple resources (10+) on each task, used for time recording
capture.

There are some potential issues with bad data in plans.  To rule out
data issues in the plan itself, try cleaning it
- Take the plan and save it locally
- Save the local plan as XML
- Open this and save as a new MPP
- Save this to the server
- Compare performance

Between these two activities you should find out where the issue(s)
are.

Notes:
is the performance the SAVE job, the PUBLISH job, or the transfer of
data thats performed prior to save (where the client locks briefly)
you said Project Server SP2 and WSS.  is WSS SP2 too (as it should be)
What version of the project client are you using?  min SP2
suggest upgrade to a recent CU across server and client (i think Oct
CU for Project Server and Project is stable and tested)
On the SQL side, you could run the SP_UPDATESTATS on each SQL DB to
see if there are reindexing activities that are updated on the tables
Has this been confirmed from other client machines (just to rule out a
client performance issue)

good luck

Carl@EPM







- Show quoted text -

Thanks for the response Carl!

We aren't using timesheets at all - so the timesheet info wouldn't
apply. The issue is in teh SAVE process on the server. THe client is
not locked up the entire time thankfully.

We have done the Save to XML process and that helped but still have
saves of 15-30 minutes.

I will look at the SQL steps you listed. Also - we have engaged
Microsoft and I will post the remedy that they come up with.