Not sure if you remember the problem we had with Daylight Savings Time last year - but basically when adding jobs to the queue they have a time when they should be processed - and most times this time is "now" or the current time. Well with the DST problem "now" was actually set in one hour's time - so some jobs just sat there for a while.
We have seen a couple of recent cases where time differences between servers can give this same problem. A server puts a job on the queue and the timestamp for "now" gets set a couple of minutes in the future - because the SQL Server machine doesn't have the same time as the Project Server machine. When the queue gets to this job it will just let it sleep until the right time arrives. This can look like a slow queue, when in fact it is doing what it is told. Keeping your servers clocks in sync will avoid this problem. The ULS logs will show this as jobs sleeping when there does appear to be any reason. In most "sleeping" cases the reason appears in the log - such as a missing custom field in the reporting DB will put a project reporting publish to sleep.
Technorati Tags: Project Server 2007
OMG! Brian - you are a genius! Thanks! We exerienced crazy 2 min slowdowns for each step in the publish process (2 min for saving, 2 min for publishing, 2 min for checking in, and 2 min for clearing the local cache....an 8 min terrible process). Thanks for rescuing us!
Ever so grateful,
Lately I’ve heard a few requests to improve the Project Server queue performance. For instance some of
Been slow on the blog the last week or two, and now two posts come along at once.  And a third may
Thank you very much for this post. I have been searching for a couple of days on the cause of the issue we are having in Project Server not processing jobs right away. This has finally resolved our problem.
This may seem like a silly question. Why is the submission of a job based on the system clock locally instead of "now" on the target? It doesn't seem very prudent to depend on W32Time when MS themselves won't support it's accuracy. Even a few seconds of difference is a perceived performance issue in this current configuration.
Hi Paul - good suggestion, but I guess there may be some implementation difficulties in getting a time in code from the right system and writing this to a remote system. Possibly ASAP might have been a better option...
I'm wondering if there would be an impact on the local Project Pro cache if the client and server clocks are not synchronized? we have seen some project check-in pending issue on client workstations lately (while the plan was checked in on the server) and I would like to make sure that clocks de-synch would not be responsible for that. Thanks!