Configure maximum job processor threads for the Project Server Queue service
This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.
The Microsoft Office Project Server 2007 Queue service allows you to configure the maximum number of processor threads for each queue type.
The Queue Settings page in Project Web Access server settings has a Maximum Number of Job Processing Threads setting whose default value is four (for each queue type). There are many things to consider when adjusting these values. Having too many job processor threads can adversely affect performance on the application server and can result in timeout and memory-exception errors. For example, an administrator may try to increase the maximum number of job processor threads from four to 10 on both the timesheet and project queues in order to address an expected increase in timesheet submittals and project updates for an end-of-month period. Without careful consideration, such an increase can adversely affect performance.
The queue is designed to limit the rate at which work gets processed so that the peaks that can overload the server get spread out. In project management terms, this is “leveling” for the server — stopping the server from trying to do too many things at once.
Queue multithreading
Because the queue is multithreaded, it can:
Process jobs quickly.
Avoid a complete stoppage of job processing when one job encounters a problem.
The following tables describe the order in which the queue would process jobs in a single-threaded queue and a multithreaded queue. In this example, three projects have been saved and published in the following sequence:
Project 1 is saved and published.
Project 2 is saved and published.
Project 3 is saved.
Project 2 is opened, edited, saved, and published again.
The following table describes how the queue would attempt to process jobs in a single-threaded environment. The column headings T1 through T9 indicate time segments. All operations would be completed at the end of the ninth time segment. Note that the first Project 2 publish job is skipped for optimization, because the queue detects that an identical Project 2 publish job occurs later. Also, reporting jobs for Project 1 and Project 2 are of lower priority, so they are processed later.
| Thread | T1 | T2 | T3 | T4 | T5 | T6 | T7 | T8 | T9 |
|---|---|---|---|---|---|---|---|---|---|
Thread 1 |
Project 1: save |
Project 1: publish |
Project 2: save |
Project 2: publish (skipped) |
Project 3: save |
Project 2: save |
Project 2: publish |
Project 1: reporting |
Project 2: reporting |
The following table describes how the queue would attempt to process jobs in a multithreaded environment (in this example, three threads). It would take more than half the time to attempt to process the same operations from the example above. Note how this environment allows for correlated jobs (for example, all jobs related to Project 1 save and publish) to all be processed on the same thread. If a job fails in the correlation, it might prohibit other jobs from being processed in the same correlation, but will not affect other jobs in other threads.
| Thread | T1 | T2 | T3 | T4 | T5 | T6 | T7 | T8 | T9 |
|---|---|---|---|---|---|---|---|---|---|
Thread 1 |
Project 1: save |
Project 1: publish |
Project 1: save |
Project 1: reporting |
|||||
Thread 2 |
Project 2: save |
Project 2: save |
Project 2: publish |
Project 2: reporting |
|||||
Thread 3 |
Project 3: save |
Recommended settings
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 take into account the farm topology and other applications that are running on the farm. For example, 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. Additionally, you can monitor performance counters, application logs, and ULS logs to guide you in fine-tuning the queue to work with your normal server loads.