Receiver performance when using JMS
Each receiver performance log message has a low-level breakdown of the percentage of thread time spent on various aspects of processing each message and message batch, as well as a summary line stating the (approximate) throughput rate over the previous measurement interval, and an indication of the minimum, mean (average) and maximum number of events in each batch that was received.
The items that may appear in the detailed breakdown are:
RECEIVING - time spent in the JMS provider's
MessageConsumer.receive() method call for each message received.
MAPPING - time spent mapping each JMS message to the corresponding Apama event. If
maxExtraMappingThreads is set to a non-zero value then this is the time spent waiting for remaining message mapping jobs to complete on their background thread(s) at the end of each batch.
DB_WAIT - (only for reliable receive modes) time spent waiting for background reliable receive database operations (writes, deletes, etc) to complete, per batch.
DB_COMMIT - (only for reliable receive modes)time spent committing (synching) received messages to disk at the end of each batch.
APP_CONTROLLED_BLOCKING - for receivers that are using
APP_CONTROLLED reliability mode, this is the time spent waiting for the EPL monitor to call the
appControlledAckAndResume() action. A monitor calls this action after it finishes processing a batch of messages from the receiver.
ENQUEUING - (only for
BEST_EFFORT and
APP_CONTROLLED receive mode) time spent adding received messages to each public context's input queue.
JMS_ACK - time spent in the JMS provider's
Message.acknowledge() method call at the end of processing each batch of messages.
R_TIMEOUTS - the total time spent waiting for JMS provider to complete
MessageConsumer.receive() method calls that timed out without returning a message from the queue or topic, per batch. Indicates either that Apama is receiving messages faster than they are added to the queue or topic or that the JMS provider is not executing the receive (timeout) call very efficiently or failing to return control at the end of the requested timeout period.
FLOW_CONTROL - the total time spent (before each batch) blocking until the EPL application increases the flow control window size by calling
JMSReceiverFlowControlMarker.updateFlowControlWindow(...). In normal usage, this should be negligible unless some part of the system has failed or the application is not updating the flow control window correctly.
TOTAL - aggregates the total time taken to process each batch of received messages.
