Application profiling performance considerations

 

+

Search Tips   |   Advanced Search

 

Application profiling enables assembly configuration techniques that improve performance. You can configure tasks that...

The application profiling service has no tuning parameters, other than a checkbox for disabling the service if the service is not necessary. However, the overhead for the application profile service is small and should not be disabled, or unpredictable results can occur.

Access intents enable you to specify data access characteristics. The WebSphere runtime environment uses these hints to optimize the access to the data, by setting the appropriate isolation level and concurrency. Various access intent hints can be grouped together in an access intent policy.

Configure bean level access intent for loading a given bean. Application profiling enables you to configure multiple access intent policies on an entity bean.

Some callers can load a bean with the intent to read data, while others can load the bean for update. The capability to configure the appserver can improve performance, efficiency, and scalability, while reducing development and maintenance costs.

Access intents enable the EJB container to be configured providing Optimal performance based on the specific type of enterprise bean.

Access intent hints can be specified declaratively at deployment time.

The application profiling service improves overall entity bean performance and throughput by fine tuning the run time behavior.

The application profiling service enables reduces worst case choices, such as pessimistic update on a bean accessed with the findByPrimaryKey method.

Application profiling provides the capability to define the following hierarchy:

Container-managed tasks identify units of work and are associated with a method or a set of methods. When a method associated with the task is invoked, the task name is propagated with the request. For example, a UOWrefers to a unique path within the application that can correspond to a transaction or ActivitySession. The name of the task is assigned declaratively to a J2EE client or servlet, or to the method of an enterprise bean. The task name identifies the starting point of a call graph or subgraph; the task name flows from the starting point of the graph downstream on all subsequent IIOP requests, identifying each subsequent invocation along the graph as belonging to the configured task. As a best practice, wherever a UOWstarts, for example, a transaction or an ActivitySession, assign a task to that starting point.

The application profile service associates the propagated tasks with access intent policies. When a bean is loaded and data is retrieved, the characteristics used for the retrieval of the data are dictated by the application profile.

The application profile configures the access intent policy and the overrides that should be used to access data for a specific task.

Access intent policies determine how beans are loaded for specific tasks and how data is accessed during the transaction. The access intent policy is a named group of access intent hints. The hints can be used, depending on the characteristics of the database and resource manager. Various access intent hints applied to the data access operation govern data integrity.

The general rule is, the more data integrity, the more overhead. More overhead causes lower throughput and the opportunity for simultaneous data access from multiple clients.

If specified, access intent overrides provide further configuration for the access intent policy.

 

Best practices

Application profiling is effective in a variety of different scenarios. The following are example situations where application profiling is useful

 

Monitor tools

You can use the Tivoli Performance Viewer, database and logs as monitoring tools.

You can use the Tivoli Performance Viewer to monitor various metrics associated with beans in an application profiling configuration. The following sections describe at a high level the Tivoli Performance Viewer metrics that reflect changes when access intents and application profiling are used:

Database tools are helpful in monitoring the different bean loading characteristics that introduce contention and concurrency issues.

These issues can be solved by application profiling, or can be made worse by the misapplication of access intent policies.

Database tools are useful for monitoring locking and contention characteristics, such as locks, deadlocks and connections open. For example, for locks the DB2 Snapshot Monitor can show statistics for lock waits, lock time-outs and lock escalations. If excessive lock waits and time-outs are occurring, application profiling can define specific client tasks that require a more string level of locking, and other client tasks that do not require locking. Or, a different access intent policy with less restrictive locking could be applied. After applying this configuration change, the snapshot monitor shows less locking behavior.

Refer to information about the database you are using on how to monitor for locking and contention.

The appserver logs can be monitored for information about rollbacks, deadlocks, and other data access or transaction characteristics that can degrade performance or cause the application to fail.


 

Related tasks

Tuning WebSphere applications