How do I Analyze Pramati Server Diagnostics?

How do I analyze Pramati Server Diagnostics?

How do I analyze Pramati Server Diagnostics?

Diagnostics help to identify and analyze the time taken to complete a logical unit of operation and provide details on the time taken by business operations for execution. It helps in distributing time across various sub-tasks and eliminate bottlenecks at runtime. In a complex application environment, monitoring transaction response times is a critical part of optimal application performance and availability.

Server enables you to meet performance and availability service levels. Server monitors predefined or selected Web transactions and provides details of response time. For critical applications, a high level of monitoring, availability, and analysis is necessary. For simple applications such as printing, a lower level of availability and monitoring is sufficient. Server performs the following functions:

Monitor and detect: Monitors the complete database environment, analyzes the data, and detects the thresholds that have been exceeded.
Diagnostics: Enables you to find out the reasons why is there a change in the threshold size.

You can start and record transactions. The end user response time is also captured. The failure of any component of an application at any level affects other components and degrades its performance. The service level time for an application can be compared and alerts are sent when response time degrades. The Server monitors, reports, stores data in files, and sends alerts when something goes wrong. For more details on alerts, read Managing Alerts.

The components in the Console are made by one or more beans called the Manageable Beans (MBeans), which are either standard or dynamic. The Console uses dynamic MBeans that conform to a specific interface and offers great flexibility at runtime. The usage of MBeans involves various advantages. These objects are simple and easy to implement. Service providers and developers can make their products manageable in a standard way without having to understand or invest in complex management systems. In addition, the MBeans generate and propagate notification events to components of the other levels.

This section covers the following aspects of the Server Diagnostics:

Diagnostics architecture in Pramati Server.
Collecting timing diagnostics data.
Timing diagnostics for transactions, datasources, and applications.
Sorting diagnostic data based on cumulative time taken to perform a task.
Viewing timing diagnostic data.
Reading and interpreting the collected diagnostic data for various tasks performed under transactions, datasources, modules, and beans in deployed applications.
Saving the recorded data.
Deleting diagnostic records.
Running integrity checks on Server sockets and acceptor threads.

What is the Server Diagnostics Architecture?

Server provides application level data profiling such as bean pool wait time or database response wait time. Historical data is available for the performance of both events. The rules engine available with Server gives support for event correlation between different nodes and easy customization. The Web browser displays the occurring events. This enables you to determine the condition of the system.

How do I collect Timing Diagnostics Data?

Timing diagnostic data is collected mainly during the deployment phase and occasionally during production environment phase. The data collected during Server runtime can be used to trace the cause of the problem. All diagnostic details collection are switched on and off simultaneously.

In the Explore panel, select Analyze > Server Diagnostics. The Server Diagnostic page is displayed. You can browse for a specific report and include it in the report list using the Load button.

What does the Diagnostics Toolbar look like?

The toolbar in Diagnostics home page displays the following options:

Start: Starts the process of collecting diagnostics.
Note: Clicking Start for the first time displays a link to view current data.
Stop: Stops collecting diagnostics data.
Save: Saves the diagnostic data collected.
Note: The diagnostics data is temporary. Once the Server is stopped, the data is lost if it is not saved. The standard Save option does not save diagnostic data.
Refresh: Refreshes the page. Displays the Server Diagnostics Report page.
Note: The standard Refresh button does not refresh the page.
Trash: Deletes the selected item.
Close: Closes the diagnostics window.

Click Start. A link to View current data is displayed. Click this link to view diagnostic details in Server.

The following timing diagnostics details are available on the home page:

Transactions: Diagnostics for transactions committed and rolled back.
Datasources: Time taken to connect to the datasources for the applications running on the Server.
Applications: Application modules.

How do I collect Timing Diagnostics for Transaction?

A J2EE-based application server supports infrastructural services such as transactions. This is used by deployed application components for activities detached from business logic. Transaction service on the Server is based on Java Transaction API (JTA) 1.0.1 specification.

To ensure optimal performance and availability of applications, it is necessary to obtain diagnostic data on transaction response times. To obtain timing diagnostics data for transactions occurring at Server run time:

Select Transactions from the diagnostics home page or the Explore panel. It displays the following details for the selected MBean:
Table 1: Transaction Diagnostics page

Name Description

Total Transaction Commit (ms) Overall time taken to commit all the transactions.

Total Transactions Rollback (ms) Overall time taken for transactions to rollback.

Click the MBean to view the diagnostics summary by task. For each task, the data on total number of hits, average time taken, and the cumulative time taken to serve the requests is collected and displayed. This diagnostic data is used to construct a histogram to simplify interpretation.
Click any task to view the method name, package, module type, number of hits, average time taken to finish a transaction, cumulative time taken to complete a particular transaction, and a histogram based on the data available for the selected task.

Name	Description
Total Transaction Commit (ms)	Overall time taken to commit all the transactions.
Total Transactions Rollback (ms)	Overall time taken for transactions to rollback.

How do I collect Timing Diagnostics for Datasources?

Server diagnostics provide information on datasource availability, historic information on capacity of database resources, sends alerts, and enables you to drill down to the problem. This simplifies the process of resolving performance issues.

Select Datasources from the home page or from the Explore panel to view the datasource diagnostics. It gives the following details:
Table 2: Datasource Diagnostics

Field Description

Datasources List of the datasource names accessed to run a particular application.

Total Wait Time to Obtain Conn (ms) The time required to connect to the datasource.

Select the required datasource. The name and type of datasource and various datasource task details, such as the methods accessed, hits, average time taken to complete a particular task, and the cumulative time taken to serve the total number of requests is displayed.
Note: In addition to these tasks, various prepared statements for the current data source are also listed.
Click any task to view the method name, package, module type, number of hits, average time taken to finish a transaction, cumulative time taken to complete a particular transaction, and a histogram based on the data available for the selected task.

Field	Description
Datasources	List of the datasource names accessed to run a particular application.
Total Wait Time to Obtain Conn (ms)	The time required to connect to the datasource.

How do I collect Timing Diagnostics for Applications?

It is important to monitor applications to detect performance degradation issues and solve them. Server enables the administrator to monitor a complex and distributed application environment. This creates a highly efficient and well managed system.

Select Applications from the home page or from the Explore panel. All applications that are deployed on the Server are listed.
Select an application to view the application modules.
Select a war or jar module:
- Selecting a war displays the application name, module name, servlets under the selected module, and the service time for each method.
- Selecting a jar displays details about the application and module name, beans involved along with the time taken for activation, passivation, to load, store data, and to obtain and release a lock.
Select the required component to view details such as application name, module name, name of the component, and type of the component.
Note: For a war module, the component is of servlet type. For a jar module the component is of bean type. In addition to the standard tasks, application specific business methods are also listed.
Select a task to view the number of hits, the average and cumulative time taken to complete the task, along with a histogram based on the available data.

How do I sort Diagnostic Data?

Server diagnostics tool is used for profiling J2EE Applications with Pramati Server services such as JDBC resources and transactions. This feature helps clients in troubleshooting. For deployment modules that contain a large number of Servlets and EJBs, the data is sorted such that you can quickly locate the performance bottleneck. The queries that take a lot of time are displayed in descending order, sorted by the cumulative time taken to perform a task.

Sorting of Servlet or EJBs

Given the object name of a servlet or EJBs of any application running on Server, these statistics are rendered by the Diagnostics GUI. This process is repeated for the complete set of components of any deployed module.

What is the impact of sorting on Performance?

Sorting any data structure is bound to have a performance impact. The sorting algorithm is a modified merge-sort that guarantees n*log(n) performance and uses linear performance approach on nearly sorted lists. Considering that the Diagnostics Tool is turned on on-demand and is GUI-based, the time taken to sort the data in order to improve usability is acceptable.

How do I view sorted Diagnostic Data?

To view the sorted data from the Console, select Analyze > Sever Diagnostics. Select a deployed application, for example, OrderBook.ear. The results are sorted based on cumulative time, and displayed at three levels:

Level 1: Lists the components of any deployed module. All the Servlets or JSPs in the Web component are sorted based on cumulative time.
Level 2: Gives details of the business method for a bean or service method for a JSP.
Level 3: Each task that contributes to the processing of a business or service method can be explored further to know the time taken by sub-tasks like prepared statement execution time, bean load time etc.

How do I interpret Diagnostics?

Consider the example of the bank application.

Start the Server.
Using Deploy Tool, open BankDesk.ear available at <install_dir>\server\samples\ejb11\BankDesk\ear\. Click Deploy to deploy the application.
On the Console, select Analyze > Server Diagnostics. It displays the Server Diagnostic home page.
Click Start on the tool bar. It displays a new link to View current data.
Open a browser and start the application by entering the URL as http://127.0.0.1:8181/bankWeb/bank.jsp. Create two accounts, 1111 and 2222 with initial balances of Rs. 5,000 each using the New Account tab. Then, using the Transfer tab, transfer Rs.1,000 from account number 1111 to 2222.
Click View Current Data. It displays the Diagnostics page.
Note: The application may run on the local or a remote server. Server collects diagnostic data for both cases. Click Refresh to view the diagnostic data for the request sent to Server.

How do I read Transaction Diagnostics?

Select Transactions. It displays the corresponding details. You can check for the nature and details of transactions. Click on the MBean to view the following details:

Table 3: Method descriptions for Transaction MBean

Method Name	Description
Transaction Commit	Implies that a transaction has been committed.
Transaction Heuristic Mixed	Implies that the transaction was not committed because of data corruption.
Total Transaction	Indicates the total number of transactions that have occurred.
Transaction Rollback	Implies that a transaction has rolled back.
Transaction Heuristic Rollback	Implies that the transaction was not committed because of some network problem. The database or resource is not affected by this rollback.
Transaction Set Rollback	Implies that the transaction was not committed because of a logic specified in the code.

You can select the Transaction Commit method from the list and study the drill down on the following page.

How do I read Datasource Diagnostics?

Selecting datasources displays the following details:

Table 4: Datasource details

Field	Options	Description
Module Name	-	Refers to the name of the deployed module.
JDBC Datasource	-	Displays the JDBC datasource details.
-	Datasources	Displays the JDBC datasource name.
-	Total wait time to obtain connection (ms)	Displays the total time required to get connected.

Click on a datasource name to view the following details:

Table 5: Datasource Diagnostics

Method	This value indicates the
wait Time To Obtain Conn	Time taken to obtain a connection from the resource pool.
waiting Thread Time	Time taken to wait for a connection from the pool. A requestor may need to wait for a connection because a new connection cannot be created due to the limitation of the pool size. Then, the requestor has to wait for one currently used connection to become available.
prep Stmt Obtained From Cache	Number of prepared statements that are retrieved from the cache.
new Conn Creation Freq	Number of times a new connection is created.
prep Stmt Created Afresh	Number of prepared statements that are created afresh. The ratio of this value and the prepStmtObtainedFromCache value can give you an indication if you need to change the value of the number-of-cached-prepared-statement tag in the server-config.xml file.
connection Use Time	Duration for which the connection is in use.
conn Available In Thread Context	Number of times an existing connection is made available to the requestor from the same transaction.

Selecting a method, for example, the connectionUseTime, displays a histogram for it.

How do I read Application Diagnostics?

Selecting Applications displays a list of deployed applications. Clicking an application, say BankDesk.ear, displays the type of the application and the components that make it.

Table 6: Application Diagnostic Details

Field	Options	Description
Type	-	Refers to the type of the deployed application. For example, J2EE application.
Components	-	Displays the wars and jars for the application.
-	Wars	Displays the Web modules for the selected application. For example, bankWeb.
-	Jars	Displays the Java modules for the selected application. For example, bankEJB.jar.

Reading Web Modules

Selecting the Web module displays the following details:

Table 7: Web Module Details

Field	Description
Module Name	Refers to the name of the selected Web module. Say, bankWeb.
Servlet	Displays the list of servlets for the module, along with the total time taken for the method.

Clicking on a Servlet name, say /transfer.jsp, displays details like the application name, module name, the servlet name, the task name, hits made for the particular task, and the average and cumulative time taken for the completion of the task.
Selecting the task name displays a histogram for the activity on the same, if there is sufficient data available.
Clicking the ‘+’ icon expands the tree and displays more details as below, while clicking the arrow icon collapses the tree view.

Reading jar Modules

Selecting the jar module displays the following details:

Table 8: jar module details

Field	Options	Description
Module Name	-	The name of the selected jar module, say bankEJB.jar.
Entity Bean	-	The details for the entity beans.
-	Beans	The name of the entity bean.
-	Total Activation Time (ms)	The total activation time for the entity bean in milliseconds.
-	Total Passivation Time (ms)	The total passivation time for the entity bean in milliseconds.
-	Total Load Time (ms)	The total load time for the entity bean in milliseconds.
-	Total Store Time (ms)	The total store time for the entity bean in milliseconds.
-	Total Locking Time (ms)	The total locking time for the entity bean in milliseconds.
Stateful Session Bean	-	The details for the stateful session beans.
-	Beans	The name of the stateful session beans.
-	Total Activation Time (ms)	The total activation time for the stateful session bean in milliseconds.
-	Total Passivation Time (ms)	The total passivation time for the stateful session bean in milliseconds.
Stateless Session Bean	-	The details for the stateless session beans.
-	Beans	The name of the stateless session beans.
Message Driven Bean	-	The details for the message driven beans.
-	Beans	The name of the message driven bean.
-	Time taken for MDBeans onMessage method call	The time taken for MDBs onMessage method call.

Reading Entity Beans

Selecting an entity bean name displays the following details:

Table 9: Reading Entity Beans

Task name	Time taken
create:java.lang.Long;double;java.lang.String;(BusinessMethod)	To execute the applications business method.
findByID:long;(BusinessMethod)	To execute the applications business method.
findAllAccounts:(BusinessMethod)	To execute the applications business method.
lockingTime	To obtain and release a lock by the bean.
postProcesingTime	To complete the tasks that are done after processing the actual business methods in the bean.
storeTime	To store data.
preProcessingTime	To complete the tasks that are done prior to processing the actual business methods in the bean.
getCustomer_name:(BusinessMethod)	To execute the applications business method.
loadTime	To load data.
activationTime	For activation.
riLockingTime	To lock a remote bean instance.
onPoolWaitingTime	To wait for getting a bean from the bean pool.
ejbActivateTime	To call the ejbActivate method.
beanGetTime	To get a bean from the bean pool.
creatingTime	To create a bean instance.
lockRowTime	To lock a row.
onCacheWaitingTime	To wait for getting a bean from the cache.
debit:double;(BusinessMethod)	To execute the applications business method.
getAccount_number:(BusinessMethod)	To execute the applications business method.
credit:double;(BusinessMethod)	To execute the applications business method.
getBalance:(BusinessMethod)	To execute the applications business method.
verifiedUpdateTime	Verify the updation of the bean.
activateLoadTime	To activate the load.
rollbackLoadTime	To rollback the load.
lockWaitingTime	To obtain a lock for the bean.
passivationTime	For passivation.

Selecting the task name displays a histogram for the activity on the same, if there is sufficient data available.

Reading Stateful Session Beans

Selecting a stateful session bean name displays the following details:

Table 10: Reading Stateful Session Beans

Task name	Time taken
createEntry:long;java.lang.String;double;(BusinessMethod)	To execute the applications business method.
createEntry:long;java.lang.String;double;(ActualMethod)	To execute the applications actual method.
create:(BusinessMethod)	To execute the applications business method.
preProcessingTime	To complete the tasks that are done prior to processing the actual business methods in the bean.
getLedgerRows:(BusinessMethod)	To execute the applications business method.
getLedgerRows:(ActualMethod)	To execute the applications actual method.
postProcesingTime	To complete the tasks that are done after processing the actual business methods in the bean.
onPoolWaitingTime	To wait for getting a bean from the bean pool.
beanGetTime	To get a bean from the bean pool.
aliveTime	For which the bean is in existence.
creatingTime	To create a bean instance.
ejbActivateTime	To call the ejbActivate method.
activationTime	For activation.
riLockingTime	To lock a remote bean instance.
passivationTime	For passivation.

Selecting the task name displays a histogram for the activity on the same, if there is sufficient data available.

Reading Stateless Session Beans

Selecting a stateless session bean name displays the following details:

Table 11: Reading Stateless Session Beans

Task Name	Time taken
transfer:long;long;double;(BusinessMethod)	To execute the applications business method.
transfer:long;long;double;(ActualMethod)	To execute the applications actual method.
preProcessingTime	To complete the tasks that are done prior to processing the actual business methods in the bean.
beanGetTime	To get a bean from the bean pool.
onPoolWaitingTime	To wait for getting a bean from the bean pool.
create:(BusinessMethod)	To execute the applications business method.
postProcesingTime	To complete the tasks that are done after processing the actual business methods in the bean.
creatingTime	To create a bean instance.
riLockingTime	To lock a remote bean instance.

How do I save Diagnostic Data?

To save and store diagnostic data in the local server:

Click Save.
Enter a name for the report to be saved.
Clicking Save displays the following message: ‘The report has been saved by name "<name _moz-userdefined="">"’. The report can be accessed later from the diagnostics home page.
Note: Use Cancel to abort the process.
Click Continue to view other diagnostic data. Click Close on the toolbar to exit Diagnostics.

How do I view Diagnostic Data?

To view diagnostic data:

Locate the saved reports listed under Reports on the Server Diagnostics Reports page.
Select the required report and click Download Report. The file download dialog-box opens.
Select Open this file from current location to view diagnostic data. Select Save this to disk to make a local copy.

How do I delete Diagnostic Data?

To delete diagnostic data from the Server, click Trash on the toolbar. If data is saved as a report, select the reports to be removed and click Delete.

How do I run Integrity Check on Server Sockets and Acceptor Threads?

You can choose a value of socket time-outs and thread counts by analyzing statistics about sockets and threads, generated by Statistics and Diagnostics. This enables you to carry out a persistent integrity check on the number of threads and their health.

If there is a conflict between configured number of threads and number of existing threads, necessary steps are taken. If actual number of threads is more than the configured number, some threads are killed; if the actual number of threads is found to be less than the configured number then some new threads are created; if some threads are not alive, new threads are created. The functional details are described in the subsequent sections.

Persistent check on the health of Server socket is also carried out. The Server socket response time is measured. This helps in accessing the performance degradation of Server under load.

What is the impact of Integrity Check on Server Performance and Configuration?

Integrity Check does not effect the performance of Server. Modules and properties such as server-config.xml, deploy-config.xml, MBeans, SPIs, ANT Handler, command line interface, Web Console etc. do not suffer any negative impact of integrity check.

What are the considerations for running Integrity Check for Acceptor Threads?

While running an integrity check on acceptor threads, the following factors are considered:

Acceptor thread Count: It is the conflict between configured thread count and actual thread count. If actual thread count is more than the configured count, some of the acceptor threads will be terminated and if the actual thread count is found to be less than the configured count then some more acceptor threads will be created.
State of threads: A persistent check is carried out on the health of threads. The dead threads are removed from the list and new threads are created to replace them.

What are the considerations for running Integrity Check for Sessions?

Integrity check considerations for a session are:

Session count: This is the number of active session with the Server. Integrity check of actual sessions count and the PramatiTimerThread counts.
Session closing: This includes the number of sessions that are closed after time-outs, the number of sessions closed by the client, and the number of sessions closed after invalidation.

What are the considerations for running Integrity Check for Sockets?

Integrity check considerations for Server sockets are:

ServerSocket health: This is a persistent check on the health of a socket whether or not it is accepting requests.
Response time: This is the current response time of the Server for a known request versus the time taken on load for the same request to detect degradation of performance.
Socket closing: The number of sockets that are closed after time-out and by the client because of denial of service is checked.

What is an Integrity Check Log?

For a normal integrity check, no log file is generated. In case of an error, the details are logged in server-TXTservermsg.log file which is located in <install_dir>\server\nodes\<node_name>\logs. The message logged when the Server socket is not responding to client requests is provided as an example:

# Start Action Block: (Feb 24, 2006 12:53:35 PM162)
Main message ID: WEB0096;
SEVERE WARNING:Server Socket is not RespondingSevere;
Tip:

Messages Trace:
WEB1100;
Problem occurred. Connection refused: connect:
ConnectException while trying to connect to ServerSocket.
Retrying...;
Info;(web.core.ConnectionIntegrityTester)
WEB1100;
Problem occurred. Connection refused: connect:
ConnectException while retrying to connect to ServerSocket.
Please contact Pramati Support.;
Info;(web.core.ConnectionIntegrityTester)
WEB0096; SEVERE WARNING:Server Socket is not Responding;
Severe;(web.core.ConnectionIntegrityTester)
Exception Stacks:

## END Action Block RECORD NO:162##

The message logged when a new thread is created appears as given in the following example:

## Start Action Block: (Feb 24, 2006 12:57:12 PM108)
Main message ID: WEB0098;
new acceptor threads createdInfo; Tip:
Messages Trace:
  WEB0098;
  new acceptor threads created;Info;(web.core.HttpHealthChecker)
 Exception Stacks:

## END Action Block RECORD NO:108##

The message generated when a thread is killed appears as:

## Start Action Block: (Feb 24, 2006 1:04:00 PM122)
Main message  ID: WEB0100;
acceptor threads more than configured number.killing extra threads.Info;
Tip:
Messages Trace:
 WEB0100;
 acceptor threads more than configured number.killing extra threads.;
 Info;(web.core.HttpHealthChecker)
 Exception Stacks:
## END Action Block RECORD NO:122##

How do I disable Integrity Check?

Integrity check option is enabled by default. To disable it, set the following property in runserver.bat as:

set TEMP=%PATH%
call D:\PramatiServer\server\bin\setup.bat
java.exe
-Dinstall.root=%install.root%
-Djava.security.policy=%install.root%\lib\pramati\pramati.java.policy
-Djava.security.auth.policy=%install.root%\lib\pramati\pramati.jaas.policy
-Dorg.xml.sax.parser=org.xml.sax.helpers.XMLReaderAdapter
-Dorg.xml.sax.driver=org.apache.crimson.parser.XMLReaderImpl
-Dweb.header.checkintegrity = false com.pramati.Server %1 %2 %3 %4 %5

To re-enable this feature, shutdown and restart Server.


© Pramati Technologies 2007	Runs on Pramati Server \| Feedback \| Legal