Large schedule size normal?

[crizco]

Hello

I've been reading the threads regarding schedule size and slow down and just
got my first case at work. We run Project Server 2003 (SP2a), and have one
schedule that is 1,155 lines. It's been getting slower and slower for our PM.
She had 512MB of RAM on her computer and was experiencing Low Virtual Memory
pop ups from time to time. Updates are becoming so slow and even opening the
file takes 2.5 minutes. When I saved a copy of her file, it was 45MB. A week
later, I saved it again and now it's 65MBs! Her schedule goes out to 2010 and
has lots of assignments. I just tried testing it with some of the methods
mentioned in the Corruption/Bloat file from MSVPs FAQs. The file still
remains around 65MB. It's not as slow on a test site (no PServer or other
network connections ect), but even though I've tried the "bloat" methods, it
still remains around 65MB. So I'm thinking the file size is normal and it has
to be her RAM and network slow down.

Is this file size normal for this project? Why would it be that huge! Can
timephased data add lots to projects that go out for 3 + years? If I know her
file size is normal, then I can concentrate on the network environments
(Project Server is new to our organization so most don't know where to look).
Any thoughts?

 

[James Fraser]

Hello

I've been reading the threads regarding schedule size and slow down and just
got my first case at work. We run Project Server 2003 (SP2a), and have one
schedule that is 1,155 lines. It's been getting slower and slower for our PM.
She had 512MB of RAM on her computer and was experiencing Low Virtual Memory
pop ups from time to time. Updates are becoming so slow and even opening the
file takes 2.5 minutes. When I saved a copy of her file, it was 45MB. A week
later, I saved it again and now it's 65MBs! Her schedule goes out to 2010 and
has lots of assignments. I just tried testing it with some of the methods
mentioned in the Corruption/Bloat file from MSVPs FAQs. The file still
remains around 65MB. It's not as slow on a test site (no PServer or other
network connections ect), but even though I've tried the "bloat" methods, it
still remains around 65MB. So I'm thinking the file size is normal and it has
to be her RAM and network slow down.

Is this file size normal for this project? Why would it be that huge! Can
timephased data add lots to projects that go out for 3 + years? If I know her
file size is normal, then I can concentrate on the network environments
(Project Server is new to our organization so most don't know where to look).
Any thoughts?

I can't say off the top of my head whether that file size is normal,
but it doesn't stand out as unreasonable. Yes, time phased data and
the number of assignments can add significantly to the file size.

The one thing I can say with certainty is that, due to the
architecture of PS 2003, the latency of the network connection to the
server can cause a lot of grief. Ping to the _database_ server from
the workstation in question. The "time" in those results should be as
small as possible. For large projects, I think things get painful if
this number is more than 10ms. (Microsoft's official recommendation
used to be 30ms, IIRC.) If you are using this project plan across a
WAN, investigate ways to change that.

The couple hundred dollars for additional RAM (labor included) to get
to 1GB will likely yield a large improvement as well, unless this user
is running no other applications.

And my last suggestion: consider turning off Auto calculations within
Project Professional. Then the cascading calculations will only happen
on demand.


James Fraser

 

[Gary L. Chefetz [MVP]]

Crizco:

Try the instructions here and let us know how it goes:
http://www.projectserverexperts.com/Shared Documents/BinaryRebuild.htm

--

Gary L. Chefetz, MVP
MSProjectExperts
For Project Server Consulting: http://www.msprojectexperts.com
For Project Server FAQS: http://www.projectserverexperts.com

 

[crizco]

Sorry I took a long time to update this, but we have been working feverishly
trying to figure out this problem. Basically the database tables were clean -
except for the timephased table being questionably large.

One of the Microsoft reps we've been working with pointed out that we had a
lot of baselines (5 in this particual schedule). He suggested to save the
file locally and clear all of them to see if there was file reduction. I
couldn't believe it!!!! It went from 66MB to 6.8MB! I guess every time you
add baselines to the entire project (especially if it's a large one) it's a
snapshot of a LOT of data (which would explain the timephased piece being so
large)! Locally, this large data load was never a problem, but on a server
going through networks it was.