Queue Settings (Project Server 2010 settings)

Queue Type

The Queue Type setting lets you select the queue to which the settings on the page apply. The options are the Project Queue (which processes job types such as Project Save and Publish) and the Timesheet Queue (which processes job types such as Timesheet Save and Notifications).

Maximum Number of Job Processor Threads

The Maximum Number of Job Processor Threads setting determines how many job processor threads are available for use for the selected queue type (Project or Timesheet).

As a starting point, we recommend that you set the maximum number of processor threads settings based on the number of available processors (or cores). For example, if the Project Server application server uses a single dual-core processor, configuring the settings for two threads per queue is a good starting point. If your application server uses a quad dual-core processor, you might be able to use eight threads per queue. You can adjust these settings accordingly based not only on the volume of transactions, but also the average size of the transactions (for example, publishing 10-line projects versus 1000-line projects).

You should also think about the farm topology and other applications that are running on the farm. If you have four application servers on the farm and if you set the Maximum Number of Job Processor Threads setting to 4, it gives you the potential for 16 threads to be operating. You should adjust the setting accordingly if your application server is also serving as a front-end Web server or running search or other processor-intensive activities.

Along with the consideration of the processing power of application servers, it is important to consider the throughput of the computer that is running SQL Server that is hosting the Project Server databases. For instance, suppose that you have eight application servers that can process threads and the Maximum Number of Job Processor Threads setting is at 4 (potential for 32 threads all processing jobs). SQL Server may start having contention issues because all the threads are operating on the same table.

Additionally, you can monitor performance counters, application logs, and ULS logs to guide you in fine-tuning the queue to work with your typical server loads.

Polling Interval (in milliseconds)

The Polling Interval setting lets you specify the time interval (in milliseconds) in which the Queue NT Service polls the project or timesheet database (depending what you selected for Job Type) for new jobs. The valid range is 500 through 300000, with a default value of 1000.

Retry Interval (in milliseconds)

The Retry Interval setting lets you set the length of time (in milliseconds) between retries for jobs that have failed through SQL-related issues, such as SQL deadlocks. The valid range is 0 (immediate retry) to 300000, with a default value of 1000.

Retry limit

The Retry limit setting lets you set the limit on retries on a failed polling query. The Project Server Queuing System polls the databases on a regular basis to retrieve jobs that need processing. If this query should fail for an SQL-related reason, the system will attempt to poll the database again after a time.

SQL retry interval (in milliseconds)

The queue polls the database at set intervals for jobs that need processing. If the query fails, the SQL Retry Interval setting lets you set the length of time (in milliseconds) before the query is retried. The valid range is 0 (immediate retry) to 60000, with a default value of 1000.

SQL retry limit

The queue polls the database at set intervals for jobs that need processing. If the query fails, the SQL retry limit setting lets you set the number of times the query will be retried. The valid range is 0 (no retries) to 100, with a default value of 5.

SQL Timeout (in seconds)

The queue makes SQL calls for retrieving and executing jobs. This SQL Timeout setting lets you set the time-out value (in seconds) for these calls. If any job fails because of an SQL Timeout error, you can increase the value for this setting and retry the job. The valid range is 30 to 86400 (one day), with a default value of 1800 (30 minutes).

Cleanup Interval (in hours)

The Cleanup Interval setting lets you configure the frequency (in hours) with which the Queue Cleanup job runs. The valid range is 1 to 100000, with a default value of 24 (one day). For example, if the cleanup interval is set to the default value of 24, the Queue Cleanup job will run every 24 hours. You can set the time which the Queue Cleanup job will run with the Cleanup Interval Offset setting.

Cleanup Interval Offset (in minutes)

The Cleanup Interval Offset setting determines the time at which the queue cleanup job will run. The default value is 0, which sets the cleanup to occur at 12:00 A.M. The valid range is 0 (12:00 A.M.) to 1439 (11:59 P.M.). Use this together with the Cleanup Interval setting. For example, if the Cleanup Interval Offset value is set to 180, and the Cleanup Interval value is set to 24, the Queue Cleanup job will run daily at 3:00 A.M.

You may want to use the Cleanup Interval Offset to run after the cube service is scheduled to run. In this situation, if the cube service starts at midnight, you may want to postpone the cleanup to occur some hours after midnight.

Cleanup Age Limit for Successful Jobs (in hours)

The Cleanup Age Limit for Successful Jobs setting lets you configure when a job that has been completed successfully is removed from the system. You can configure this setting by entering the value (in hours) in the Cleanup Age Limit for Successful Job field. The value that you enter configures the queue to delete the job during the cleanup interval, only if the age of the successfully created job is equal to or greater than that value.

For example, you configure the Cleanup Age Limit for Successful Jobs value to be 24 (default value). Cleanup Interval Offset is configured to clean up jobs at 12:00 A.M. daily. If you have a publish job that completed successfully on 11:55 P.M. on September 1, it is not removed from the system until September 3 at 12:00 A.M. when it is over 24 hours old. The September 2 12:00 A.M. cleanup does not remove the job because it is only five minutes old.

Cleanup Age Limit for Non-Successful Jobs (in hours)

The Cleanup Age Limit for Non-Successful Jobs setting lets you configure when a job that has completed in an unsuccessful state is removed from the system. You can configure this setting by entering the value (in hours) in the Cleanup Age Limit for Non-Successful Job field. The value that you enter configures the queue to delete the job during the cleanup interval, only if the age of the unsuccessful job is equal to or greater than that value. The method in which unsuccessful jobs are removed from the system is identical to the way successfully completed jobs are removed from the system.

The default value of this setting is 168 hours (7 days). Since job status information is important in helping to troubleshoot problems when a job has not completed successfully, we recommend not to set this value to less than the default setting.

Bookkeeping Interval (in milliseconds)

There are several "bookkeeping" tasks that are run by the Queuing System. For example, these include awakening jobs in a "sleeping" state, updating the heartbeat time stamp, or checking whether the Queue Cleanup job needs to be run. The Bookkeeping Interval setting controls the time interval (in milliseconds) at which these tasks are run.

The valid range is 500 to 300000, with a default value of 10000 (ten seconds).

Queue Timeout (in minutes)

In a farm that contains multiple Application servers, if the Queue Service fails on one of the servers, jobs are automatically distributed among the remaining Application servers on which the Queue Service is active. A Queue Service is considered to have timed out if it has not updated its heartbeat for longer than the Queue Timeout value (in minutes). The heartbeat is updated by the Queue in all the Project Web App databases that it touches (for example, every time that the Published and Draft databases are polled for jobs).

The valid range is 2 to 20, with a default value of 3.

Fast Polling

By default, the Fast Polling setting is enabled, and it allows the queue to process all jobs in a Waiting to be Processed state to be processed as soon as possible. However, if this fast processing overwhelms the server and the Queue has to slow down, this setting can be disabled.

If Fast Polling is disabled, the Queue checks whether there are any free threads to process jobs. If there are, the free threads are loaded with jobs in a Waiting to be Processed state. It then waits for the polling interval and repeats the process.

If Fast Polling is enabled, the Queue does not wait for the polling interval if there are pending jobs. As jobs get processed, all pending jobs get processed immediately.

See Also

Concepts

Guía del administrador de Project Server 2010
Manage Queue Jobs (Project Server 2010 settings)