Udostępnij za pośrednictwem

  • Artykuł

Test queue settings in Project Server 2010

 

Applies to: Project Server 2010

Topic Last Modified: 2011-11-21

Summary:  The seventh article in a series of nine articles about how to test a Microsoft Project Server 2010 deployment as an enterprise project management system administrator or solution tester. Use the series as a guide to test the functionality of a newly deployed Project Server 2010 instance. The articles in this series discuss the functionalities that are on the Server Settings page, and some initial tests that you can run to connect and check server communications by using the Project Professional 2010 client application.

Contents

  • Manage queue

  • Queue settings

  • Next steps

Manage queue

See Plan the application tier (Project Server 2010) for detailed information about how the queue works from a technical perspective.

The following are some examples:

  • When you perform a save transaction, the request is sent to the queue and the client-side cache and the queue then ensures that the transaction is completed.

  • When you create a new resource, the request is sent to the queue, and the queue creates the resource.

  • When you publish, the queue manages the synchronization transactions between the Draft database, Published database, and Reporting database.

The queue is read-only. Only applications such as Project Professional 2010 and Microsoft Project Web App can make entries into the queue.

Test Step Expected / Desired Results Actual Results (if deviation)

1. Open Project Web App.

The Project Web App loads.

2. Click Server Settings.

The Server Settings page appears.

3. Click Manage Queue.

    (Located in the Queue section.)

The Manage Views web page appears.

4. Open Project Professional 2010 and publish a project.

5. Refresh the queue page.

The page displays the list of items in the queue, including the project publish transaction.

6. Open the Delete Enterprise Objects page and then delete a timesheet.

7. Open the queue page again after issuing the timesheet delete transaction.

The page displays the timesheet delete transaction.

Note

Take note of the following:

  • Progress of the queue – % complete is shown for each transaction in the queue.

  • Job State – example if the queue transaction fails it will provide the details of why.

  • If an error occurs, click the link in the error column – this loads a web page that contains detailed information about the error.

The width of the field changes according to the width that you specify.

Queue settings

Project Server 2010 has the following queues:

  • A Timesheet queue that contains processed transactions related to Timesheets.

  • A Project queue that contains processed transactions related to Projects/Resources.

Test Step Expected / Desired Results Actual Results (if deviation)

1. Open Project Web App.

The Project Web App loads.

2. Click Server Settings.

The Server Settings page appears.

3. Click Queue Settings.

    (Located in the Queue section.)

The Queue Settings page appears.

Queue settings values

Value Description

Queue Type

Choose the Queue to which the settings apply. The options are the Project Queue, which processes job types such as Project Save and Publish, or the Timesheet Queue, which processes job types such as Timesheet Save and Notifications. Note that all the Queue Settings are per PWA site, and per Queue Type.

Maximum Number Of Job Processor Threads

The Queue is multi-threaded, which enables multiple jobs to be processed at the same time. If the number of current job processor threads equals the limit, no more threads are created. Note that this setting is per PWA site, and per Queue Type.

  • Minimum: 1

  • Maximum: 20

  • Default: 4

Polling Interval (in milliseconds)

The time interval at which the Queue polls the database for new jobs.

  • Minimum: 500 (.5 second)

  • Maximum: 300000 (5 minutes)

  • Default: 1000 (1 second)

Retry Interval (in milliseconds)

If job processing fails because of transient issues (like a SQL Deadlock), instead of failing the job, the Queue will wait for the Retry Interval to elapse and then retry the job.

  • Minimum: 0 (immediately retry)

  • Maximum: 300000 (5 minutes)

  • Default: 1000 (1 second)

Retry limit

If job processing fails because of transient issues (like a SQL Deadlock), instead of failing the job, the Queue will retry the job. The number of retries is bound by the Retry Limit.

  • Minimum: 0 (no retries)

  • Maximum: 100

  • Default: 5

SQL retry interval (in milliseconds)

The Queue polls the database at set intervals to retrieve jobs that need processing. If this query fails due to a transient SQL problem (like a SQL Deadlock), the Queue will wait for the SQL Retry Interval to elapse and then retry the query.

  • Minimum: 0 (immediately retry)

  • Maximum: 60000 (1 minute)

  • Default: 1000 (1 second)

SQL retry limit

The Queue polls the database at set intervals to retrieve jobs that need processing. If this query fails due to a transient SQL problem (like a SQL Deadlock), the Queue will retry the query after the SQL Retry Interval has elapsed. The number of retries is bound by the SQL Retry Limit.

  • Minimum: 0 (no retries)

  • Maximum: 100

  • Default: 5

SQL Timeout (in seconds)

The Queue makes SQL calls for retrieving and executing jobs. This setting controls the time-out value for all such calls. If any job fails due to a SQL Timeout error, administrators can increase this setting and retry the job.

  • Minimum: 30

  • Maximum: 86400 (1 day)

  • Default: 300 (5 minutes)

Clean-up Interval (in hours)

This setting determines the frequency with which the Queue Clean-up job runs. The time of day at which the Queue Clean-up job runs is determined by the Clean-up Interval Offset setting.

  • Minimum: 1

  • Maximum: 100000

  • Default: 24 (1 day) Clean-up Interval (in hours)

Clean-up Interval (in hours)

This setting determines the frequency with which the Queue Cleanup job runs. The time of day at which the Queue Cleanup job runs is determined by the Cleanup Interval Offset setting.

  • Minimum: 1

  • Maximum: 100000

  • Default: 24 (1 day)

Clean-up Interval Offset (in minutes)

This setting is the number of minutes after 12:00 a.m. (midnight) at which the Queue Cleanup job will run. The frequency with which the Queue Cleanup job runs is determined by the Cleanup Interval setting.

  • Minimum: 0 (cleanup 12:00 a.m.)

  • Maximum: 1439 (cleanup at 11:59 p.m.)

  • Default: 0 (cleanup at 12:00 a.m.)

Clean-up Age Limit for Successful Jobs (in hours)

This setting determines the age threshold at which successful jobs can be purged when the Queue Cleanup job runs. The age of each job is determined by the completed date and time. For example: If a job succeeded at 2/1/2007 10:41 p.m. and the Queue Cleanup job runs at 2/2/2007 11:55 p.m., then the job will be purged (assuming the Cleanup Age Limit For Successful Jobs was 1 day). Because the number of successful jobs is usually high, the Cleanup Age Limit For Successful Jobs setting is usually set to a low value of 24 (1 day).

  • Minimum: 1

  • Maximum: 100000

  • Default: 24 (1 day)

Clean-up Age Limit for Non-Successful Jobs (in hours)

This setting determines the age threshold at which any job in a completed, non-successful state (example: Failed But Not Blocking Correlation) can be purged when the Queue Cleanup job runs. The age of each job is determined by the completed date and time. For example: If a job was canceled at 2/1/2007 10:41 p.m. and the Queue Cleanup job runs at 2/2/2007 11:55 p.m., then the job will not be purged (assuming the Cleanup Age Limit For Non-successful Jobs was 7 days). Because the number of completed, non-successful jobs is usually not high, the Cleanup Age Limit for Non-successful Jobs setting is usually set to a high value of 168 (7 days).

  • Minimum: 1

  • Maximum: 100000

  • Default: 168 (7 days)

Bookkeeping Interval (in milliseconds)

There are several Bookkeeping tasks that the Queue System executes. Some examples are as follows: awakening jobs in 'Sleeping' state, updating the heartbeat time stamp, checking whether Queue Cleanup needs to be executed, and so on. This setting controls the time interval at which these tasks run.

  • Minimum: 500 (1/2 second)

  • Maximum: 300000 (5 minutes)

  • Default: 10000 (10 second)

Queue Timeout (in minutes)

The Queue System has a failover recovery feature: if the farm contains multiple servers that are running the Project Application Service, and the Queue Service fails on one server, jobs are automatically redistributed to other servers on which the Queue Service is online. A Queue Service is considered to have timed out if it has not updated its heartbeat for more than the 'Queue Timeout' interval. The heartbeat is updated by the Queue in all the PWA databases that it handles.

  • Minimum: 2

  • Maximum: 20

  • Default: 3

Note

The Queue Timeout cannot be less than 4 times the Bookkeeping Interval at any time. For example, if the Queue Timeout is 3 minutes and the Bookkeeping Interval is changed to 60000 (60 seconds), then the Queue Timeout will automatically be changed to 4 minutes.

Fast Polling

By default, this setting is enabled and the queue processes all 'waiting to be processed' jobs as soon as possible. But if this fast processing overwhelms the server and you want the queue to slow down, administrators can turn off Fast Polling. If the setting is off, the queue does the following: Check if there are any free threads to process jobs and if there are, load all the free threads with the 'waiting to be processed' jobs, wait for the polling interval and repeat the process again. If the setting is on, the queue does not wait for the polling interval if there are pending jobs. As jobs get processed, the pending jobs are processed immediately.