Is it normal for a project save / check in to take 5-6min to compl

[Uriah]

We have recently implemented Project Server 2007 in the following config.

Project Server 2007 x64 edition and PWA running on a Dual Core Dual CPU 3Ghz
with 4GB RAM running Windows 2003 SP2 x64. It connects to a SQL 2005 x64
server which is a Quad Core Dual CPU 2.66Ghz with 8GB RAM running Windows
2003 SP2 x64.

We never had Project Server before so there was no upgrade only importing
existing Project plans created in Project Pro 2007.

What we find strange and Project managers find very fustrating is that a
save or check in of a project is taking up to 5-6 min. There is also little
feedback to the user in Project Pro 2007 so they were just closing it. This
was causing projects to get hung in a checked out stage and the project
manager would call us to force a check in of the project. Once we realized
why this was happening we are having them wait however based on the hardware
we don't understand why the long save / check in times. Does the save /
check in rely on the local system at all?

In checking the event viewer I have noticed the following error generated
however it doesn't happen everytime they save a project

----------

Standard InformationSI Entry Point:
Project User: domain\username
Correlation Id: f7ce4a98-99f8-4cae-a260-e21cece41a68
PWA Site URL: http://epm/PWA
SSP Name: EPMSharedServices
PSError: GeneralQueueJobFailed (26000)
A queue job has failed. This is a general error logged by the Project Server
Queue everytime a job fails - for effective troubleshooting use this error
message with other more specific error messages (if any), the Operations
guide (which documents more details about queued jobs) and the trace log
(which could provide more detailed context). More information about the
failed job follows. GUID of the failed job:
f7ce4a98-99f8-4cae-a260-e21cece41a68. Name of the computer that processed
this job: EPM (to debug further, you need to look at the trace log from this
computer). Failed job type: ProjectCheckIn. Failed sub-job type:
FailIfNotCheckedOutMessage. Failed sub-job ID: 2. Stage where sub-job failed:
(this is useful when one sub-job has more than one logical processing
stages).

-----------

Any suggestions or pointers would be greatly appreciated. At this point I
haven't been able to find anyone else on the net experiecing a similiar issue
however it seems that Project Server 2007 is very new and not widely deployed.

Thanks,

 

[Brian Smith \(MSFT\)]

Hi Uriah,

The save time will depend on a number of things - so difficult to say if
this is normal or not. I'll give you some background on what happens with a
save and you might be able to see what in your environment could be taking
the time.

When the user hits "save" then the first part of the save is to the local
cache (normally on their local machine). This can be monitored by the blue
bar on the left of the status bar. If the local cache is on a network
location this could slow things down. Once this part is finished then the
synchronization to the server begins. The data is then moving from the
users local cache to the server queue. The status on the client can again
be monitored - this time in the centre of the status bar. Once the message
changes from Synchronizing.... to Save Job 0%... then all the data is on the
server and the client can be closed (File Close rather than Alt-F4 or the X
in the corner - to avoid a check-in bug). If the network connection is slow
then this step could take a while - but the data transfer is much faster
than in Project Server 2003. I know you haven't used that - but other
readers may find that useful. From the queue once all the data is received
and the job gets to the top of the queue then the data moves from the queue
message table into the Project Server tables. This can take a while if the
project is very large in terms of numbers of tasks, has many baselines,
and/or many task level custom fields. This is sort of equivalent to the
save process from Project Pro 2003 to Server 2003. If the client still has
the project open they will see the progress go up as the queue job gets
processed.

So is 5-6 minutes a long time? For a small project in a fast network with
the sort of hardware you have outlined it does seem longer than I would
normally expect - but if the server is busy or the project large it could
take this long.

Sorry it isn’t a yes/no answer but hopefully the background to what is going
on may help your understanding of the potential bottlenecks.

Best regards,

Brian.

 

[lily]

Did you get this resolved? We had the same issue and there were a lot of
determining factors. Customizations, multiple baselines but more importantly
we had a job stuck inthe queue from the past with a state of "Getting Queued".

Go into Manage Queue and change your job history back to when you first
installed and make sure the "all job completion states" are selected except
for "success". Click the "Refresh Status" and look for a job with a job
state of "Getting Queued". If you do have one then go to "Advanced Options"
above the job grid and select "Cancel Jobs Getting Enqueued". Then go to the
job grid and select the job with the Getting Queued state and then select
cancel. It should cancel the job. Cancel all other jobs as well just to
clean it out.

Removing the customizations and stuck jobs significantly improved our
performance.

Hope this helps.

 

[PedroJose]

Hi,

The problem we are having is that the Project pro 2007 client will show the
"synchronizing data to server" for a while, then the connection is lost, but
the synchronizing message is still there as well as the "connected" message
at the bottom.... I've found that if you click on the "connected" status
window, disconnect and then re-connet (sometimes more than once!!!), the
synchronizing message will change to "saving 0%...." then it just saves, not
the fastest but it goes through. How can the connection issue be
resolved??? what are we doing that may not be right???

please advise.

thanks,