Measures reported by PSQueueGeneralTest
A queue is a waiting line that becomes a necessity when the number of service requests becomes greater than the optimum serving capacity.
The purpose of the Office Project Server Queuing System is to handle such abrupt changes in demand gracefully and reliably. The Office Project Server Queuing System takes all the users' input, records entries for the requests in Microsoft SQL Server, and then processes the data asynchronously on a first-come, first-served basis. Having a queue ensures that the Office Project Server does not stop working when a spike in demand occurs.
The Office Project Server Queuing System is composed of two separate queues:
- Project Queue: Primarily used for project-related messages such as Saving, Publishing, Reporting, and Cube Building, although other types of messages may be sent to this queue as well. Its tables and stored procedures are stored in the Office Project Server Draft database.
- Timesheet Queue: Primarily used for timesheet-related messages such as Timesheet Save and Timesheet Submit, although other types of messages may be sent to this queue as well. Its tables and stored procedures are stored in the Office Project Server Published database.
The two queues are designed the same way, except that their jobs reside in different databases.
The true test of the efficiency of these queues lies in how quickly they process the requests lined up within. If a queue consists of too many unprocessed jobs, it is a clear indicator of a processing bottleneck in the queue, which if not cleared promptly, can end up overloading the Microsoft Project Server and significantly degrading its overall performance. To pre-empt such slowdowns, administrators will have to continuously track the jobs in each queue, look out for a steady growth in queue length, and make sure that the queue is configured with enough processing power to handle its current and anticipated load. This is where the PSQueueGeneralTest test helps!
This test monitors each queue of the Project server, counts the unprocessed jobs in every queue, and thus pinpoints the queue that is unable to process requests quickly. By reporting the number of threads the queue is currently using for processing requests, the test also indicates whether/not the lack of enough processor threads is the reason for the poor processing ability of the queue. This way, the test not only alerts administrators to a processing bottleneck in a queue, but also leads to the probable cause of the same.
The measures made by this test are as follows:
| Measurement |
Description |
Measurement Unit |
Interpretation |
| Active_job_processing |
Indicates the number of threads that are currently active - i.e., the threads that are currently processing jobs in this queue. |
Number |
Comparing the value of this measure across queues will reveal the queue which has the highest number of threads that are currently processing the jobs. |
| Avg_job_unprocessed |
Indicates the average number of jobs that remain unprocessed per day in this queue. |
Number |
A consistent increase in the value of this measure is a cause for concern, as it could indicate that the workload of the queue is steadily increasing, but the queue is unable to handle this load. In such situations, you may want to time-correlate the values of this measure with that of the Active_job_processing measure. If this analysis reveals that the queue is not employing more threads to handle the additional load, it could mean that the queue does not have more processor threads. You may then want to consider fine-tuning the maximum thread configuration of the queue. To do this, you will have to use the Queue section in the Queue Settings page of the Microsoft Project Server 2010 Server Settings page. In this section, you can configure the Maximum Number of Job Processor Threads. This setting determines how many job processor threads are available for use for the selected queue type (Project or Timesheet). Before modifying this setting, consider the following recommendations:
- As a starting point, Microsoft recommends 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.
|
| Curr_job_unprocessed |
Indicates the number of unprocessed jobs that are currently in this queue. |
Number |
If the value of the Curr_job_unprocessed measure is abnormally high, you may want to compare the value of the New_job_per_min measure with that of the Curr_job_unprocessed measure to know exactly when the spike occurred - in the last minute? Or after that? |
| New_job_per_min |
Indicates the number of new jobs that entered this queue in the last minute. |
Number |
| Sqlcalls_per_min |
Indicates the number of SQL calls made per minute by this queue. |
Number |
|
| Sqlretries_per_min |
Indicates the number of SQL calls that were retried per minute by this queue. |
Number |
The queue polls the database at set intervals for jobs that need processing. If the query fails, then you can configure the queue to retry the query a specific number of times. Likewise, you can also configure the interval between retries.
A high value for these measures could indicate one/all of the following:
- Too many queries are failing;
- The SQL retry limit is set to a high value, allowing too many retries;
- The SQL Retry Interval is set to a low value, allowing queries to be retried frequently;
|
| Sqlretries_per_hr |
Indicates the percentage of SQL calls that were retried per hour by this queue. |
Percent |
|