Apama 10.3.1 | Apama Documentation | Connecting Apama Applications to External Components | Correlator-Integrated Support for the Java Message Service (JMS) | Using the Java Message Service (JMS) | Designing and implementing applications for correlator-integrated messaging for JMS | Performance considerations when using JMS | Sender performance when using JMS
 
Sender performance when using JMS
Each sender 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 sent.
The items that may appear in the detailed breakdown are:
*MAPPING - time spent mapping each Apama event to the corresponding JMS message. This includes the time spent looking up any JMS queue, topic, or JNDI destination names, unless cached.
*SENDING - time spent in the JMS provider's MessageProducer.send() method call for each message.
*JMS_COMMIT - time spent in the JMS provider's Session.commit() method call for each batch of sent messages (only if a JMS TRANSACTED_SESSION is being used to speed up send throughput).
*WAITING - the total time spent waiting for the first Apama event to be passed from EPL to the JMS runtime for sending, per batch. This is affected by what the EPL code is doing, and for reliable sender modes, also by the (dynamically tuned) period of successful correlator persist cycles.
*BATCHING - the total time spent waiting for enough Apama events to fill each send batch, after the first event has been passed to the JMS runtime.
*TOTAL - aggregates the total time taken to process each batch of sent messages.

Copyright © 2013-2019 | Software AG, Darmstadt, Germany and/or Software AG USA, Inc., Reston, VA, USA, and/or its subsidiaries and/or its affiliates and/or their licensors.