Components dashlet

To diagnose and fine-tune component management services like Enterprise Java Beans, AppMon uses dynamic bytecode instrumentation to capture performance metrics, including Java remoting metrics, across horizontal and vertical application layers. A central AppMon Server correlates the resulting measurements to PurePaths Dashlet.

The Components dashlet displays the collected metrics.

Components dashlet
Components dashlet

Metrics

The dashlet displays the following information:

  • Platform: The software platform (Java or .NET) for the component.
  • Method: The name of the called method.
  • Class: The name of the class that implements the component interface.
  • Type: The component type on which the method was called. Currently supported component types are:
    • Local Call: Local call to an Entity or SessionBean.
    • Remote Call: Remote call to an Entity or SessionBean.
    • HomeInterface: Call to a HomeInterface.
    • Local HomeInterface: Call to a local HomeInterface.
    • SessionBean: Server-side execution of a SessionBean method.
    • MessageDrivenBean: Server-side execution of a MessageDrivenBean method.
  • Count: The number of times the particular component method has been called or executed.
  • Total Avg [ms]: The average time, in milliseconds, for all executions of this component method.
  • Total Min [ms]: The minimum time, in milliseconds, for an execution of this component method.
  • Total Max [ms]: The maximum time, in milliseconds, for an execution of this component method.
  • Total Sum [ms]: The accumulated time, in milliseconds, for all executions of this component method.
  • Exec Avg [ms]: The average time, in milliseconds, for all executions of this component method, excluding time spent in nested method calls.
  • Exec Min [ms]: The minimum time, in milliseconds, for an execution of this component method, excluding time spent in nested method calls.
  • Exec Max [ms]: The maximum time, in milliseconds, for an execution of this component method, excluding time spent in nested method calls.
  • Exec Sum [ms]: The accumulated time, in milliseconds, for all executions of this component method, excluding time spent in nested method calls.
  • CPU Avg [ms]: The average CPU time, in milliseconds, for all executions of this component method.
  • CPU Min [ms]: The minimal CPU time, in milliseconds, for an execution of this component method.
  • CPU Max [ms]: The maximum CPU time, in milliseconds, for an execution of this component method.
  • CPU Sum [ms]: The accumulated CPU time, in milliseconds, for all executions of this component method.

Context menu options

  • Create Measures: Open the Measure Configuration dialog box to add measures to a subscription. This option is only available during real-time sessions.
  • New Business Transaction: Open the Business Transaction Editor dialog box to create a new Business Transaction based on the selection related measures. This option is only available during real-time sessions.
  • Source Lookup: See Source Lookup Feature for a detailed description.
  • Add Sensor Rules (only available on live sessions)
    • Refine with Callee Methods: All Methods that are called by the Selected Methods are retrieved and can be used as input for new Inclusion Sensor Rules.
    • Exclude Selected Methods: All Selected Methods can be used as input for new Exclusion Sensor Rules.
    • Include Selected Methods: All Selected Methods can be used as input for new Inclusion Sensor Rules.

Sensor Configuration

Use the Configure Sensor Properties dialog box for the EJB Invocation Sensor to specify whether to instrument plain setter and getter methods of components. By default, these methods are instrumented. Select the options if you do not want them instrumented. Methods instrumented by the RMI Sensor are also affected by these settings, because EJB invocations are often related to RMI calls.

To access the dialog box:

  1. In the System Profile Preferences dialog box, expand an Agent Group in which the EJB Invocation Sensor Pack is placed, and select Sensor Configuration.
  2. Click Properties for the EJB Invocation Sensor Pack.

Tuning options

Follow these guidelines to tune performance based on the metrics previously described.

  • Use local calls. When caller and callee are located in the same JVM, access EJBs using local calls to bypass stubs and skeletons (actually the whole RMI), and security checks.
  • Use value objects. To reduce network overhead, avoid single remote calls by using the Value Object Pattern.
  • Use stateless session beans.
  • Remove unneeded stateful session beans. Removing these objects avoids a passive state for these beans, and the attendant disk operations.
  • Cache EJB references. To avoid a JNDI lookup for every request, cache EJB references in servlets.
  • Cache home interfaces. Because repeated lookups to a home interface can be expensive, cache references to EJBHomes in the init() methods of servlets.
  • Cache EJB resources. Use setSessionContext() or ejbCreate() to cache bean resources. This is an example of using bean lifecycle methods to perform application actions only once where possible. Remember to release acquired resources using the ejbRemove() method.
  • Explicitly call remove(). Allow stateful session EJBs to be removed from the container cache by explicitly calling of the remove() method in the client.
  • Tune the entity EJB´s pool size. Entity beans use both the EJB pool and cache settings. Tune the entity EJB´s pool size to minimize the creation and destruction of beans. Populating the pool with a non-zero steady size is useful for getting better response for initial requests.
  • Cache bean-specific resources. Use the setEntityContext() method to cache bean-specific resources. Release them using the unSetEntityContext() method.
  • Load related data efficiently for container-managed relationships (CMRs).
  • Configure read-only entity beans for read-only operations.
  • Use container-managed transactions. These transactions are preferred for consistency, and provide better performance.
  • Don't encompass user input time. To avoid resources being held unnecessarily for long periods, a transaction should not encompass user input or user think time.
  • Identify non-transactional methods. Declare non-transactional methods of session EJBs with NotSupported or Never transaction attributes. These attributes can be found in the ejb-jar.xml deployment descriptor file. Transactions should span the minimum time possible, because they lock database rows.
  • For very large transaction chains, use the transaction attribute TX_REQUIRED. To ensure EJB methods in a call chain, use the same transaction.
  • Use the lowest-cost database locking that is consistent with any transaction. Commit the data after the transaction completes rather than after each method call.
  • Use XA-capable data sources only when two or more data sources are going to be involved in a transaction.