The Talon Manual

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Note

Per transaction stats are currently classified as an experimental feature. While this feature is a supported feature, it is subject to refinement and change in the future releases.

Users are advised to carefully test the performance impact of enabling per transaction stats particularly when operating under load, as it collection and reporting of these stats can be quite costly in terms of CPU usage, disk write bandwidth and disk space usage.

...

Per transaction stats collection can be enabled with the capturePerTransactionStats configuration property for an application, and configuring a dedicated binary transaction log using the perTransactionStatsLogging configuration element. Per transaction stats collect collection collects timestamps recorded timestamps that are computed from capture when recording message latency stats, ODS store latency stats and transaction latency stats, so those must be enabled as well to be included in per transaction stats. The DDL configuration block below shows a typical set of configuration for collecting all per transaction stats: 

...

FieldDescription
transactionIdThe transactionId to which the stats correspond
timestampThe timestamp at which the transaction stats were saved to disk (in milliseconds)
transactionStartTsMicros

Captures the time, in microseconds, at which the transaction was started – the first event or message received for the transaction.

commitStartTsMicros

Captures the time, in microseconds, at which transaction commit ststarts

storeCommitStartTsMicros

Captures the time, in microseconds, at which store commit starts.

If the engine is not configured with a store this timestamp may be omitted or set to 0.

storeCommitStartedTsMicros

Captures the time, in microseconds at which the portion of store commit done by the application's business logic thread completes.

If the engine is not configured with a store this timestamp may be omitted or set to 0.

storeCommitCompleteTsMicros

Captures the time, in microseconds, that store commit completes (e.g. ack from backup instances, or flush to disk).

If the engine is not configured with a store this timestamp may be omitted or set to 0.

sendCommitStartTsMicros

Captures the time, in microseconds, at which commit (send) of outbound messages starts.

If the transaction does not contain outbound messages this may be ommitted omitted or set to 0.

sendCommitStartedTsMicros

Captures the time, in microseconds, at which outbound sends are committedcomitted. Message send commit still continues in the background.

If the transaction does not contain outbound messages this may be ommitted omitted or set to 0.

sendCommitCompleteTsMicros

Captures the time, in microseconds, at which all sends have been written to their buses and acknowledged (if GuarantteedGuaranteed).

If the transaction does not contain outbound messages this may be ommitted omitted or set to 0.

commitCompleteTsMicrosCaptures the time, in microseconds, at which the transaction is considered complete (both store and send commit completed).
inboundMessageTimings[]

Lists timings assocated associated with inbound messages in the transaction.

outboundMessageTimings[]Lists timings assocated associated with outbound messages in the transaction.

...

FieldDescription
transactionOutSequenceNumber

The outbound sequence number of the message with respect to other outbound messages in the transaction.

transactionInSequenceNumberThe inbound sequence number of the message that triggered the send.
SMACreateTsMicrosThe timestamp, in microseconds, at which the message was created (or reincarnated from a pool)
AEPSendEnterTsMicrosThe timestamp, in microseconds, at which the AepEngine send call for the message was entered.
AEPSendExitTsMicrosThe timestamp, in microseconds, at which the AepEngine send call for the message completed.
AEPSendCommitTsMicrosThe timestamp, in microseconds, at which the message was commited during the transaction commit.
SMASendStartTsMicrosThe time at which the sending thread begins sending the message over the message bus.
SMAPreSerializeTsMicrosThe timestamp, in microseconds, just before the message was serialized for send.
SMAPostSerializeTsMicrosThe timestamp, in microseconds, just after the message was serialized for send.
SMAPreWireTsMicrosThe timestamp, in microseconds, just before the serialized message was written to the bus.
SMAPostWireTsMicrosThe timestamp, in microseconds, just after the serialized message was written to the bus.
SMASendEndTsMicrosThe time after which send is completed for the message (excluding asynchronous acknowledgement).

Correlating Timings to Logged Messages

The AepMonInbound MessageTimings and AepMonOutboundMessageTimings above described the transactionOutSequenceNumber and transactionInSequence numbers associated with each timing. Below is a sample of what the transaction log entries might look like in EventSourcing app with adaptive batching enabled for an app named 'processor' thate receives 3 NewOrderMessages: 

processor.log

The recovery log would contain the inbound messages used for recovery

EntrytransactionIdsimpleClassNametransactionInSequenceNumberTransactionOutSequenceNumber
11NewOrderMessage10
21NewOrderMessage20
32NewOrderMessage10
42NewOrderMessage20

procesor.out.log

The outbound message log would contain the outbound messages

EntrytransactionIdsimpleClassNametransactionInSequenceNumberTransactionOutSequenceNumber
11NewOrderEventMessage11
21NewOrderAckMessage12
31NewOrderEventMessage23
41NewOrderAckMessage24
52NewOrderEventMessage11
62NewOrderAckMessage12
72NewOrderEventMessage23
82NewOrderAckMessage24

procesor.txnstats.log

One entry per transaction, with inbound and outbound timings entry for each message in the transaction:

EntrytransactionIdsimpleClassName

AepMonInboundMessageTimings[] insnos

AepMonOubtoundMessageTimings[] insno/outsnos
11

AepMonTransactionStatsMessage

1 and 21/1, 1/2, 2/3, 2/4
22

AepMonTransactionStatsMessage

1 and 21/1, 1/2, 2/3, 2/4

Archiving TxnStats logs

To include txnstats logs with an application's recovery and messages logs, the transaction log tool's archive command accepts a '-s' to indicate that it should be included.   

...

The TransactionStatsLogTool  expects all transaction logs that are to be queried to be located in the same folder and accepts 3 arguments:

  1. recoveryLogPath: The main receovery recovery transaction log path, corresponding ".in.log" and ".out.log" and the "txnstats.log" are opened if they existing in the same directory. 
  2. query: The transaction log query that selects entries from the logs. 
  3. outputFileName: The name of the output file to which to write the results. 

...