5
Performance and Scalability

This chapter discusses the following topics:

• Performance Overview
• Basic Tuning Tips
• Propagation Tuning Tips

Performance Overview

Queues are stored in database tables. The performance characteristics of queue operations are similar to underlying database operations. The code path of an enqueue operation is comparable to SELECT and INSERT into a multicolumn queue table with three IOTs. The code path of a dequeue operation is comparable to SELECT, DELETE, and UPDATE operations on similar tables.

Advanced Queuing in the Oracle Real Application Clusters Environment

Oracle Real Application Clusters can be used to ensure highly available access to queue data. The tail and the head of a queue can be extreme hot spots. Since Oracle Real Application Clusters may not scale well in the presence of hot spots, limit normal access to a queue from one instance only. If an instance failure occurs, messages managed by the failed instance can be processed immediately by one of the surviving instances.

Advanced Queuing in a Shared Server Environment

Queue operation scalability is similar to the underlying database operation scalability. If a dequeue operation with wait option is issued in a shared server environment, the shared server process will be dedicated to the dequeue operation for the duration of the call, including the wait time. The presence of many such processes can cause severe performance and scalability problems and can result in deadlocking the shared server processes. For this reason, it is recommended that dequeue requests with wait option be issued using dedicated server processes. This restriction is not enforced.

Basic Tuning Tips

Advanced Queuing table layout should be considered similar to a layout with ordinary database tables and indexes.

Running Enqueue and Dequeue Processes Concurrently--Single Queue Table

Some environments need to process messages in a constant flow, thus requiring that both enqueue and dequeue processes run concurrently. If the message delivery system has only one queue table and one queue, all processes must work on the same segment area at the same time, which impedes delivering a high number of messages at reasonable performance levels.

The best number for concurrent processes must be defined according to available system resources. For example, on a four-CPU system, it is reasonable to start with two concurrent enqueue and two concurrent dequeue processes. If the optimal number of messages that should be delivered through the system has not been achieved, rather than increasing the number of processes, use several subscribers for load balancing.

Running Enqueue and Dequeue Processes in Serial--Single Queue Table

When enqueue and dequeue processes are not running concurrently, that is, messages are first enqueued and then dequeued, contention on the same data segment is lower than in the case of concurrent processes. In this case, the total time taken to deliver messages by the system is longer than when they run concurrently. Increasing the number of processes helps both enqueuing and dequeuing. The message throughput rate is higher for enqueuers than for dequeuers when the number of processes is increased. Normally, the dequeue operations throughput is much less than the enqueue operation (INSERT)throughput because dequeue operations perform SELECT, DELETE, and UPDATE.

Propagation Tuning Tips

Propagation can be considered a special kind of dequeue operation with an additional INSERT at the remote (or local) queue table. Propagation from a single schedule is not parallelized across multiple job queue processes. Rather, they are load balanced. For better scalability, configure the number of propagation schedules according to the available system resources (CPUs).

Propagation rates from transactional and nontransactional (default) queue tables vary to some extent because Oracle determines the batching size for nontransactional queues, whereas for transactional queues, batch size is mainly determined by the user application.