What are Processing Units (PU)?
A Processing Unit (PU) is a job-queuing and processing station with a collection of tasks that a job or request will be undergoing after it is submitted to the Strategy Intelligence Server. There can be as many as one PU for every task that any job of a particular nature can undergo or just one PU that contains all of the tasks for all the jobs. A PU configuration involves selecting number of PU's, tasks for each of the PU, a Queue structure for each PU and thread allocation for these PU's.
When a job is submitted to the Server, it is handled by a series (or just one) of PUs each of which contains the pre-configured tasks.
The selection of the PUs to complete the job and the sequence of the PU's that shall be invoked depend on the nature of the job. However, the PU-task configuration should be selected such that each task is assigned to at least one PU. Otherwise, jobs may fail when one of its task does not have any PU associated.
Even though users can define any number of PUs and assign different tasks to each PU arbitrarily, it makes sense to collect the related tasks in a PU, otherwise the job will be required to hop between various PUs in order to execute all the tasks. Thus, reducing the hops between PU should be one goal in PU-task configuration. On the other hand, pooling all tasks in one PU will serialize the flow of jobs. To gain better job processing concurrency, it is desirable to separate tasks that can be skipped for some jobs into a different PU.
The number of PUs and the tasks assigned to each PU can greatly affect the server throughput. If a single PU is constructed, then there is no overhead of job hopping from thread to thread, one thread does all tasks for each job. On the opposite end, if each task is put in a different PU of its own, then maximum pipeline throughput can be achieved because bottlenecking tasks do not stop jobs that do not need those tasks and more threads can be assigned to the bottlenecked tasks automatically. The ideal situation is usually in-between these two configurations and different configurations are better suited to different projects, based on usage patterns. In general, the number of job hops from PU to PU should be minimized while isolating bottlenecking tasks that are not necessary for all jobs to different PUs.
To optimize the PU-task configuration, it is useful to know the nature of jobs and their load characteristics. Analyzing the job-statistics can give a good idea of which tasks bottleneck the system and which tasks can be separated into a separate PU for parallel job execution flow.
What are the Queue Structures?
Queue structures help distribution of jobs to different threads within the Strategy Intelligence Server. A queue structure is a hierarchical organization of jobs queued at a PU. Particularly, the concept of 'subqueue' is within Queue structures help implement the concept of 'prioritization' of jobs used in Strategy Intelligence Server 6.x and earlier. The hierarchical organization of the queues allows better control over resource (threads, database connections) allocation to jobs based on their priority. One can visualize the concept of subqueuing easily as follows:
In the above figure, subqueue-1 is a grouping of three threads for each subqueue of Queue-1 whereas Queue-2 holds only one subqueue with four threads. The subqueues of Queue-1 are configured to span a range of priorities, for example from the 'High', 'Medium' or 'Low'; thus, providing higher or lower priority of jobs when threads execute jobs. The default behavior for the threads assigned to lower priority queues is to take up jobs queued at higher priority if there are no jobs at the lower priority.
Note that a subqueue is a queue in itself, but since queues are sufficient to distribute jobs with sufficient priority control, subqueue's should not be used unless there is a need for 'prioritization' of tasks within the queue.
The configuration of the job prioritization is available within the desktop interface. In the front end, users specify the number of threads for 'Low', 'Medium' or 'High' priority. In the back end, these threads are translated to the number of threads that will be allocated for each one of the three subqueues within the 'QueryExecution' PU root queue.
Strategy Intelligence Server handles the creation, prioritization and allocation of its Subqueues, Queues in other PUs internally. However, it is possible to customize these values for better performance within a specific environment using the Strategy Intelligence Server Application Programming Interface (API). By default, the following PUs are configured for a Server definition: 'Browsing', 'Resolution', 'QueryExecution', 'AnalyticalPU', 'SQL Engine', 'CommandPU', 'DataFormattingPU', 'PerfCountersCommandPU' and 'Datamart PU'.
