...
The following output threads can be enabled to trace statistics, which is useful for testing and performance tuning. Enabling these output threads is not required for collecting stats. Statistics trace output is not zero garbage, so in a production scenario it usually makes more sense to collect stats via Server StatisticsXvm Heartbeats, which emits zero garbage heartbeats with the above statistics.
...
By default, an AEP engine does not collect message type specifc stats. The following configuration switches on collection of stats for message types:
nv.aep.<engineName>.msgtype.stats=true
For example, the following would switch on message To enable message type specific stats for the 'forwarder' engine.
nv.aep.forwarder.msgtype.stats=truethe following should be set in you DDL config:
| Code Block | ||||
|---|---|---|---|---|
| ||||
<apps>
<app name="MyApp">
<captureMessageTypeStats>true</captureMessageTypeStats>
<app>
</apps
<servers>
<server name="MyXVM">
<hearbeats enabled=true">
<includeMessageTypeStats>true</includeMessageTypeStats>
</heartbeats>
</server>
<servers> |
Transaction Latencies
Transaction latencies traced by an engine stats thread includes summary statistics for various phases within the transaction processing pipeline. The meaning of these summary statistics is as follows:
...
- Message receipt and send statistics described above per message type
- Histograms for application processing and filtering times.
| Anchor | ||||
|---|---|---|---|---|
|
...