What does this parser information mean for my message flow?

Although the overview parser statistics help you to identify which message flow domain has an issue, they cannot give the detail that is needed for you to rectify the problem. Therefore, to narrow down the search for the problem, the output from the parser manager must be captured.

mqsireportproperties inode_name -e IntegrationServerLabel -o ComIbmParserManager -r > parserStats.txt

This command produces a hierarchical output report that contains details of every parser that was created on every thread. This report is a 'point in time' report, such that if a message flow is in the middle of parsing a message, then the statistics are reported at that point. Therefore, to get an accurate representation, this command must be run after message flows finish processing their input messages.

Thread
  threadId='4'
  threadName='myMessageFlowName'
  totalParsers='7'

The threadName is generally a message flow name. If threadName is reported as Thread-N, then this thread is an internal one that is doing work on behalf of the integration server. If a message flow has extra instances, then there is a thread block for each instance thread where each name is the same message flow; that is, the parser report is not grouped by message flow.

Parser
   name='XMLNSC'
   address='0x7f3fd8d89640'
   type='xmlnsc'
   isShared='FALSE'
   creationTime='2014-09-03 11:05:42.437368'
   lastUsedTime='2014-09-03 11:05:42.437376'
   totalTimesUsed='1'
   approxMemKB='35801.94'
   fields='228649'
   totalFieldsUsed='228649'

How do I match a parser to the summary?

Is the parser related to a shared variable?

How well is the parser reused?

If the parser statistics contain many parser records where the totalTimesUsed is 1, and the creationTime and lastUsedTime are both the same, then this message flow is not using parsers efficiently.

How big is the parser?

It is important to remember, this information indicates how large a cached parser is, NOT how large a message tree is.

This distinction is an important one. A message tree contains names, namespaces, and values; these statistics do not take these contents into consideration.

When a parser is assigned to do work, it uses its resources to form the current message tree. These resources might be smaller or larger than the last time it was used to form a message tree. If the new message tree is smaller, the parser reuses its existing cached elements. If the new message tree is larger than any encountered before, then the parser allocates new message tree fields to handle the size of the new message tree.

By default a parser never destroys any message tree fields that it creates, even when it is not in use or parsing a smaller message tree than before.

The ApproxMemKB metric is an estimate of storage that the fields themselves are occupying in kilobytes. As previously stated, this value does include data that was in a specific message tree such as names, namespaces, and values. As such, this metric is intended to give a base for comparison from one message flow to another.

The fields metric indicates how many cached fields this parser is associated with. This number never reduces, even if the DELETE FIELD command is used, because deleted fields are reused.

The totalFieldsUsed metric is a cumulative total of all fields that were used each time that the parser was used. This metric is intended to be used with the totalTimesUsed metric to determine an average number of fields that are used per message. For example, a parser might have 200 cached fields but have a totalFieldsUsed value of 500. This value of 500 might come from 5 parses where the following number of elements are used: 100, 50, 50, 200, 100. Therefore, 200 is the maximum tree size that is created, and as such this value matches the total cached fields.