Project Server Queues Test

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 2007 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 2007 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 2007 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 Project Server Queues 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.

Target of the test : A Microsoft Project Server

Agent deploying the test : An internal agent

Outputs of the test : One set of results for each queue that is to be monitored.

Configurable parameters for the test
Parameters Description

Test Period

How often should the test be executed.

Host

The host for which this test is to be configured.

Port

The port at which the specified host listens. The default port is Null.
Measurements made by the test
Measurement Description Measurement Unit Interpretation

Active job processing threads

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.

Average unprocessed jobs

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 threads 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.

Current unprocessed jobs

Indicates the number of unprocessed jobs that are currently in this queue.

Number

If the  value of the Current unprocessed jobs measure is abnormally high, you may want to compare the value of the New jobs measure with that of the Current unprocessed jobs measure to know exactly when the spike occurred – in the last minute? Or after that?

New jobs

Indicates the number of new jobs that entered this queue in the last minute.

Number

SQL calls

Indicates the number of SQL calls made per minute by this queue.

Number

 

SQL retries per minute

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;

SQL retries per hour

Indicates the percentage of SQL calls that were retried per hour by this queue.

Percent