Queue Settings (Project Server 2010 settings)
Applies to: Project Server 2010
Topic Last Modified: 2011-12-30
The Queue Settings are available through the Microsoft Project Server 2010 Server Settings page in the Queue section. For more information about related administrative settings, see Queue (Project Server 2010 settings).
The Queue Settings page lets you configure the way that the Project Server 2010 queue system operates in your environment. The Queue Settings page includes the following options:
Queue Type
Maximum Number of Job Processor Threads
Polling Interval (in milliseconds)
Retry Interval (in milliseconds)
Retry limit
SQL retry interval (in milliseconds)
SQL retry limit
SQL Timeout (in seconds)
Cleanup Interval (in hours)
Cleanup Interval Offset (in minutes)
Cleanup Age Limit for Successful Jobs (in hours)
Cleanup Age Limit for Non-Successful Jobs (in hours)
Bookkeeping Interval (in milliseconds)
Queue Timeout (in minutes)
Fast Polling
Queue settings can be configured on this page by entering a value in the corresponding settings field.
Important
Queue settings are specific per Microsoft Project Web App site.
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.
Note
Typically the number of successful jobs compared to non-successful jobs is very high. Therefore, Cleanup Age for Successful Jobs is usually set to a lower value compared to the Cleanup Age Limit for Non-Successful Jobs value.
Note
Default Project Server categories cannot be deleted.
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.
Note
Jobs that are in an Unsuccessful and blocking correlation state stay in the history until they are successfully retried or canceled. The cleanup for non-successful jobs does not affect jobs in this state.
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.
Note
The Queue Timeout value cannot be less than four times the Bookkeeping Interval at any time. If this rule is violated, the Queue Timeout value will automatically be changed to four times the Bookkeeping value.
Note
Default Project Server categories cannot be deleted.
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.