s
div | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||
|
...
Configuration Setting | Default | Description |
---|---|---|
captureTransactionLatencyStats | 10240 | Property that can be used to control the default sampling size for series stats. If the number of datapoints collected in a stats interval exceeds this size, the computation for histographical data will be lossy. Increasing the value reduces loss of datapoints, but results in greater overhead in stats collection in terms of both memory usage and pressure on the process caches. |
captureEventLatencyStats | false | Property that globally enables collection of message latency stats as messages flow through the system. These statistics include latencies in the flow outside of transaction processing. For received messages these statistics include transmission, deserialization and dispatch costs. For sent messages these include serialization and transmission costs. When set to true, timings for messages are captured as they flow through the system. Enablement of these stats is required to collect message bus latency stats. Enabling this property can increase latency due to the overhead of tracking timestamps. |
captureMessageTypeStats | false | Property that enables tracking of message statistics on a per message type basis. When set to true, timings for each message type are individually tracked as separate stats
|
messageTypeStatsLatenciesToCapture | all | Property that enables tracking of latency statistics on a per message type ba Property controlling which latency stats on a per message type basis. This property is specified as a comma separated
The values 'all' or 'none' may not be combined with other values. This value only applies when captureMessageTypeStats is true. When not specified the value defaults to all.
|
capturePerTransactionStats perTransactionStatsLogging | false | Configuration See Per Transaction Stats for more details. |
...
Messaging latencies follow the clients, channels and fails output. The following latency statistics relate to the bus manager's message handling pipeline:
Phase | Description |
---|---|
c2o | The create to send latencies in microseconds, the time in microseconds from message creation to when send was called for it.
|
o2s | The send to serialize latencies in microseconds, the time from when the message was sent until it was serialized in preparation for transmission on the wire. For an engine with a store this will include the time from the application's send call, the replication hop (if there is a store) and time through the bus manager's disruptor if detached commit is enabled for the bus manager. |
s | The serialize latencies in microseconds, the spent serializing the MessageView to its transport encoding. |
s2w | The serialize to wire latencies in microseconds, the time post deserialize to just before the message is written to the wire. |
w | The wire latencies in microseconds, the time an inbound messages spent on the wire. The time spent on the wire from when the message was written to the wire by the sender to the time it was received off the wire by the receiver. Note: that this metric is subject to clock skew when the sending and receiving sides are on different hosts. |
w2d | The time from when the serialized form was received from the wire to deserialization. |
d | The time (in microseconds) spent deserializing the message and wrapping it in a MessageView. |
d2i | The time (in microseconds) from when the message was deserialized to when it is received by the engine. This measure the time from when the bus has deserialized by the bus to when the app's engine picks it up from it's input queue (before it dispatches it to an application) handler (it includes the o2p time of the engine's disruptor). Additional time spent by the engine dispatching the message to the application handler is covered by mpproc (see the Transaction Latencies table). |
o2i | The origin to receive latencies in microseconds. The time from when a message was originally created to when it was received by the binding. |
w2w | The wire to wire latencies in microseconds, for outbound messages the time from when the corresponding inbound message was received off the wire to when the outbound message was written to the wire. |
...