Queue

Definition

The performance metrics related to the monitored queues and their associated thread activities

Technical Data

Consider the technical information about this metric subnode in the metric hierarchy:

Software Product and Version SAP Convergent Charging 5.0
Path SAP Convergent Charging | SAP CC | Queue

Description

This node groups the performance and health data about the main processing queues and their activities in the SAP CC Core Server systems. Consider the queues regarding to:

  • throughput (count of processed items)
  • latency (response times, averages)
  • and reliability

Each subnode represents a specific processing queue in an SAP CC system instance. Each queue processes specialized items using a thread pool.

Domain Monitored Queue (Technical Name)
Services based on Message TCP Stateful, Batch, Cold
Response handling in dispatcher instances Guider Response, Rater Response
Multithreaded processes (Warm-up, Activation, Allowance Purge, Cleanup) Allowance

For parallel processing and performance optimization, SAP Convergent Charging handles few queues and corresponding mechanisms. You cannot monitor all the queues because the SAP CC system does not report any performance data.

Important Note

The final usage of a queue depends on the instance type that manages the queue. For example, the final usage of the Batch queue differs in a rater instance and in a guider instance.

Definitions and Detailed Information

A queue is a collection of items in a specific order. The queues are used for interthread, nonblocking, asynchronous communication. Consider the queues regarding to throughput, latency, and reliability.

The items are commonly enqueued by a specialized thread, for example responsible to read sockets. The items are dequeued by processing threads commonly managed in the thread pool. The items are dequeued before their processing, meaning that if a queue is blocked, then it is not related to its content (head), it is related to the last dequeued item or items in case of batching. The queues could be size-constrained and so subject to specific errors when the queue is full.

The queues (and multicast services) do not provide "one-to-many" mechanism. The items (and services) are "one-to-one" meaning that there is only one consumer/receiver for one provider/sender.

All queues are in memory meaning that if the cluster goes down then the items are lost. Since the items could be forwarded (routed) there is some mechanism to retry or reply properly.

Some queues watch their items and process the expired one based on their timeout. The item still resides in queue, even after it has been replied with the common timeout status. See also the asynchronous stateful service client timeout setting and the round trip time parameter.

The queues offer the possibility to batch dequeue. The batch dequeue is managed by the consumer (see stateful service request batch size).

At the cluster level

The queues are not used in a "send and forget" mode meaning that the originating item (cluster level) is kept.
Note: The generated data file (bulk write) are queued using a "send and forget" mode in this case items are kept in case of error and file (queue) could be blocked.

The items forwarded to another queue in another instance are kept in the originating instance here the dispatcher. The dispatcher owns the client connection so is in charge of the reply. The items are not kept in the dispatcher service queues (entry point). the items are moved in other queues such as connection (gargeable) and response

The receiver may also be a sender (routing) for the same or new items. in this case this receiver provides and ensures the coherency of the item handling and failure. The receiver routes the item programmatically and based on item content.

The messaging layer offers ways to report queue full, timeout, and failures out of the receiver processing.

Note

Not all queues are monitored nor reported. Among the notable missing queues:

  • Pending messages: This queue contains the messages sent to another instance and for which the response is expected, see the connection node.
  • SQL queries: This queue contains the SQL queries to process, see RATING_SESSION_UPDATE_MAX_BATCH_SIZE.

Example

The following is an example of the queues part of the charging operation originated by the asynchronous stateful service client.
Note: See also the flow control available for this specific client.
Queues part of the charging operation Dispatcher Stateful Service Queue Item, Request, or Message Guider Stateful Service Queue Guider Connection Queue Guiding Response Queue Rater Stateful Service Queue Rating Response Queue Rater Connection Queue Queue items watch for expiration Queue items watch for expiration Queue items watch for expiration Queue items watch for expiration Stateful Dispatching - Lookup stateful Stateful - Lookup stateful Guiding Response guiding Rating Response rating Stateful - Charging stateful Guider Instance Guider Dispatcher Instance Dispatcher Rater Instance Rater

Note

There is no metric defined in SAP CC at this level. Consider the subnodes in the metric hierarchy.

Monitored Application Data

The possible subnodes are:

Additional Information

For more information, consult the following user assistance: