The trace information of the trace based performance analysis collects the performance analysis information output in a series of processing of requests until the client reaches the components of the EIS such as a database, and until the processing results are returned to the client.

The following figure shows an overview of the trace information collection by the trace based performance analysis.

Figure 7-2 Overview of trace information collection of trace based performance analysis

When a request is sent from the Web client or the EJB client, the Web server, J2EE server, and CTM output the trace information to the buffer at determined processing points. If constant output information is collected, the trace is output in the trace file (PRFTrace file) depending on the performance tracer (PRF demon). The point at which the trace is output is called the trace get point. You can set the trace collection levels (standard or detailed) in the performance tracer. The trace collection levels set in the performance tracer are called PRF trace collection levels.

When you use Management Server for operations, you can collect the trace based performance analysis file by editing the PRF trace file in the text format. On the basis of the collected trace based performance analysis file, the operations administrator can perform the entire performance and bottleneck analysis in the management domain. For details on how to collect the trace based performance analysis file and the information that is output, see 7.3 Collecting the trace based performance analysis file by using Management Server.

You can use the trace based performance analysis to collect the trace information across multiple nodes and processes in an event within the system. This helps to trace the process in a sequence of processes in which there is a bottleneck.

To obtain the trace in an event, set a uniform key for the sequence of processes of an event in the trace based performance analysis. The information of the key is added to the trace that is output at the trace acquisition point in an event. The sequence of processes can be traced in this way.

Figure 7-3 Overview of trace output depending on the trace based performance analysis

The redirector and the Web container that output the trace are referred to as the function layer. In the trace based performance analysis, trace information is output at the entrance and the exit of the following function layer. Moreover, the trace information is output as and when necessary for each process that affects the performance among the processes of the function layers. The following table describes the execution environment of the application and the applicable function layer. In the trace based performance analysis, trace information is output at the entrance and the exit of the following function layer.

Table 7-2 Execution environment of the application and the applicable function layer

Function layer	Execution environment of the application
	Execution environment of the J2EE application	Execution environment of the batch application
CTM	Y	--
Redirector	Y	--
Web container	Y	--
EJB container	Y	--
Timer Service	Y	--
JNDI	Y	Y
JTA	Y	Y
JCA container	Y	Y
DB Connector	Y	Y
RMI (communication processing)#1	Y	Y
OTS	Y	Y
Standard output, standard error output, and user log	Y	Y
DI	Y	--
Batch application execution functionality	--	Y#2
JPA	Y	--
Cosminexus JPA Provider	Y	--
TP1 inbound integrated function	Y	--
Cosminexus JMS Provider	Y	--
JavaMail	Y	--
CDI	Y	--

Legend:

Y: Applicable

--: Not applicable

#1

You can control the collection of the layer information for the function layer of RMI (communication processing). In such cases, you have to set control in the trace collection level. For details on the setting methods, see cprfstart command (Starting the PRF daemon) in the uCosminexus Application Server Command Reference Guide or cprflevel command (Displaying and changing the PRF trace collection level) in the uCosminexus Application Server Command Reference Guide.

#2

The trace information is output immediately before (immediately before invoking main method) executing the batch application and immediately after terminating the batch application. The trace information is not output at the execution of cjexecjob and cjkilljob command.

In addition to these function layers, the trace based performance analysis outputs the trace for the start process and stop process of the J2EE server, as well as when transaction timeout occurs, and when a session is generated or cancelled.

The trace information contains information such as the process ID used to get the trace information, eventID that indicates the get point, and the IP address of the client application that gets the trace get date or the trace information.

Reference note

In addition to these function layers, you can also obtain the PRF trace in the following function layers with the configuration software and related programs of Application Server:

• Cosminexus Web Services - Base
• uCosminexus TP1 Connector
• TP1/Client/J
• TP1/MQ Access
• Cosminexus RM
• HCSC server
• HCSC server (Object Access adapter)
• Service Coordinator Interactive Workflow
• HCSC server ( file adapter)
• HCSC server (Message Queue adapter)
• HCSC server (FTP adapter)
• JAX-WS Engine
• Elastic Application Data store

The key information of the trace information consists of the following elements:

Configuration of the key information

• Process ID used to obtain the key information
• IP address of the host that invoked the process of acquiring the key information
• Communication number allocated to the I/O process (PRF daemon) of the PRF trace
  If the PRF daemon is not running, the time is returned as the communication number. It is important, however, to ensure that the PRF daemon is running, because the communication number may not be unique.
  

The following two types of key information are added to the PRF trace:

• Root application information
  This is the information obtained during the process that is executed first in the sequence of the processes in every event.
  
  • In the case of J2EE application
    It is the information obtained in the redirector or the EJB client.
    
  • In the case of Batch application
    It is the information obtained immediately before executing the batch application.
    
• Client application information
  In case of J2EE application, this is the information that is set for each processing that invokes the following Enterprise Beans:
  
  • Invoking the EJB container from the Web container
  • Invoking the EJB container from the EJB client
  • Invoking the EJB container from the EJB container
  For batch applications, it is the information set immediately before executing batch application.
  

The trace based performance analysis consists of the following programs:

• PRF trace output library
  This program is embedded in each function layer of Application Server. The PRF trace output by each function layer is output in the buffer that is created in the shared memory.
  
• PRF daemon
  This is the I/O process to output the PRF trace that is output in the buffer to a file, after a certain amount of PRF trace is collected. At least one PRF daemon is invoked on each host that obtains the PRF trace. We recommend that you deploy one PRF daemon on one host.
  The following figure shows the relationship between the PRF trace output library and the PRF daemon.
  

  Figure 7-4 Relation between PRF trace output library and PRF daemon

  

The buffer area output by trace is created when the PRF daemon starts, depending on the PRF trace output library. The buffer area is created in the common memory. Any buffer area that was created in the previous invocations of the PRF daemon that is still remaining is re-used. The buffer area is not deleted when the PRF daemon that was invoked previously ends abnormally.

When the PRF daemon ends normally, the buffer data in the buffer area is output to a PRF trace file and the buffer area is deleted.

When the buffer area is insufficient, the message of KFCT26999-W might output and the PRF trace might not output at all. Therefore, you must tune the buffer size when the message is output.

The use of trace information in troubleshooting errors is explained below.

You can output the information in the trace based performance analysis and use it for troubleshooting as follows:

• When a timeout occurs during the transaction of the J2EE application or in the redirector in receiving the response, you can use the root application information that is output in the trace based performance analysis to identify the transaction and the request that timed out.
• If a failure occurs while connecting to the database, you can use the connection ID that is output in the trace based performance analysis to identify the connection in which the error occurred.