| Download Docs | Site Map | Glossary | |
|
|
|||
| bea.com | products | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > Programming WebLogic Enterprise JavaBeans > EJB Runtime Monitoring |
|
Programming WebLogic Enterprise JavaBeans
|
The runtime information collected for an EJB is substantial and can be very useful for tuning and debugging the EJB. This section discusses each of the runtime monitoring attributes and statistics collected and points you to some basic guidelines for tuning your EJB based on the information.
It is important to note that some runtime counts are only collected to calculate a ratio and are not useful in isolation. For example, the cache hit count is useless without the context of the cache access count. Together, however, one can calculate the cache hit ratio, which can be a very valuable statistic. However, some runtime attributes are useful by themselves, such as the cached beans current count, which is useful to measure the current usage of the cache.
Note: Every application is different so you should not consider these guidelines definitive.
This section gives detailed information on runtime cache attributes, including the following:
Returns the total number of beans from this EJB Home currently in the EJB cache. This information may be useful to calculate the current percentage of the configured cache capacity being utilized.
Returns the total number of attempts to access a bean from the cache. This information is useful for giving context to other counts such as cache hits.
Returns the total number of times an attempt to access a bean from the cache succeeded. This information is useful for determining the effectiveness of the EJB cache.
Returns the total number of times an attempt to access a bean from the cache failed. This information is useful for determining the effectiveness of the EJB cache.
Returns the total number of beans from this EJB Home that have been activated.
Returns the total number of beans from this EJB Home that have been passivated.
The cache miss ratio is a ratio of the number of times a container cannot find a bean in the cache (cache miss) to the number of times it attempts to find a bean in the cache (cache access). In general, the lower your cache miss ratio, the better your EJB will perform. The amount of time saved by getting a bean from the cache depends on the cost of the bean's ejbActivate method as well as the bean's cache-between-transactions setting. When a cache miss occurs, a bean must be obtained from the free pool and its ejbActivate method must be called. The more expensive it is to invoke ejbActivate, the more the cache miss will hurt performance. If the EJB is configured with cache-between-transactions set to true, the cache miss will also force the EJB container to make an extra call to the database to load the bean.
For information on what to tune in response to the cache miss ratio statistic, see "Cache Miss Ratio" in the WebLogic Server Performance and Tuning Guide.
Runtime Lock Manager Attributes
This section gives detailed information on runtime lock manager attributes, including the following:
Returns the current number of lock entries in the lock manager. This information isn't really useful for tuning an EJB but it may be helpful in detecting stale lock entries.
Returns the total number of attempts to obtain a lock on a bean. This includes attempts to obtain a lock on a bean that is already locked on behalf of the client. This information is useful for giving context to the waiter and timeout total counts.
Returns the total number Threads that have waited for a lock on a bean. This information is useful to calculate the lock waiter ratio.
Returns the total number of threads that have timed out waiting for a lock on a bean. This information is useful to calculate the lock timeout ratio.
This is the ratio of the number of times a thread had to wait to obtain a lock on a bean to the total amount of lock requests issued. For best performance, you want the lock waiter ratio to be as low as possible.
For information on what to tune in response to the lock waiter ratio statistic, see "Lock Waiter Ratio" in the WebLogic Server Performance and Tuning Guide.
This is the ratio of timeouts to accesses for the lock manager. Timeouts are very detrimental to performance and therefore, you should strive to keep your lock timeout ratio to an absolute minimum. Timeouts hurt performance on several levels. First, each thread waiting for a lock is one less thread that the server can be using to service other requests. Second, a lock timeout will result in an exception that will roll back the current transaction, erasing any work already done in the transaction and causing the current request to fail.
For information on what to tune in response to the lock timeout ratio statistic, see "Lock Timeout Ratio" in the WebLogic Server Performance and Tuning Guide
This section gives detailed information on runtime free pool attributes, including the following:
Returns the total number of times an attempt was made to get an instance from the free pool. This information is useful for giving context to the other free pool counts.
Returns the total number of times a failed attempt was made to get an instance from the free pool. An Attempt to get a bean from the pool will fail if there are no available instances in the pool. This information is useful for calculating the pool miss ratio.
Returns the total number of times a bean instance from this pool was destroyed due to a non-application Exception being thrown from it. This information is useful for calculating the destroyed bean ratio.
Returns the current number of available bean instances in the free pool. This information is useful for tracking demand for your EJB. For example, this can be important when investigating an abnormal pool miss ratio.
Returns the number of bean instances currently in use from the free pool. This information is useful for tracking demand for your EJB. For example, this can be important when investigating an abnormal pool miss ratio.
Returns the number of Threads currently waiting for an available bean instance from the free pool. This information may be useful, for example, for investigating the cause of poor application performance at a particular time.
Returns the total number of Threads that have timed out waiting for an available bean instance from the free pool. This information is useful for calculating the pool timeout ratio.
The pool miss ratio is a ratio of the number of times a request was made to get a bean from the pool when no beans were available, to the total number of requests for a bean made to the pool. The consequence of a pool miss is different for different types of beans.
A pool miss for a stateless session bean will cause the requesting thread to wait for a bean to become available in the pool. The maximum time a thread will wait is equal to the transaction timeout value for the bean.
Entity beans and message-driven beans will never wait for an instance to become available. Instead, a pool miss will cause the pool to create a new bean instance to service the request. Pool misses come at a cost since the executing thread will either have to wait for a bean to become available or have to wait for a new bean to be created. As such, it is best to try to keep your pool miss ratio to a minimum.
For information on what to tune in response to the pool miss ratio statistic, see "Pool Miss Ratio" in the WebLogic Server Performance and Tuning Guide
The destroyed bean ratio is a ratio of the number of beans destroyed to the total number of requests for a bean. The EJB specification mandates that the EJB container destroys a bean when non-application exceptions are thrown from the bean during execution. Destroying beans comes at a cost, however, because destroyed beans will likely have to be replaced with new bean instances. As a result, you should keep your destroyed bean ratio to a minimum.
For information on what to tune in response to the destroyed bean ratio statistic, see "Destroyed Bean Ratio" in the WebLogic Server Performance and Tuning Guide
The pool timeout ratio is a ratio of requests that have timed out waiting for a bean from the pool to the total number of requests made. This ratio is only valid for stateless session beans because it is the only type of bean that will wait for a bean to become available.
Other types of beans will automatically create a new instance to service a request rather than waiting. For best performance, the pool timeout ratio should be as small as possible.
For information on what to tune in response to the pool timeout ratio statistic, see "Pool Timeout Ratio" in the WebLogic Server Performance and Tuning Guide
Runtime Transaction Attributes
Note: Runtime transaction attributes are not exposed in the 8.1 Beta 1 Administration Console.
This section gives detailed information on runtime transaction attributes, including the following:
Transactions Committed Total Count
Returns the total number of transactions that have been committed for this EJB. This information is useful for calculating transaction commit ratio.
Transactions Rolled Back Total Count
Returns the total number of transactions that have been rolled back for this EJB. This information is useful for calculating transaction commit ratio.
Transactions Timed Out Total Count
Returns the total number of transactions that have timed out for this EJB. This information is useful in calculating transaction timeout ratio.
The transaction rollback ratio is the ratio of transactions that have rolled back to the number of total transactions involving the EJB. This information is useful for several reasons. First, it may be useful for signaling a problem with an application. For example, an unexpectedly high rollback ratio may be caused by a problem with a resource used by the application. It may also be useful in gauging the efficiency of an application. A high transaction rollback ratio may mean that a lot of work is being done only to eventually be rolled back, which is inefficient.
For information on what to tune in response to the transaction rollback ratio statistic, see "Transaction Rollback Ratio" in the WebLogic Server Performance and Tuning Guide
The transaction timeout ratio is the ratio of transactions that have timed out to the total number of transactions involving an EJB. Timeouts can be especially concerning because they are a signal of inefficiency.
Every EJB request uses valuable server resources such as threads and bean instances. A timed out transaction means that server resources were tied up in vein. The transaction timeout ratio is a good indicator of a problem with an application.
For information on what to tune in response to the transaction timeout ratio statistic, see "Transaction Timeout Ratio" in the WebLogic Server Performance and Tuning Guide
This section gives detailed information on JMS attributes, including the following:
The JMSConnection Alive field tells you whether the EJB container has successfully connected to the JMS destination source and that therefore the message-driven bean is receiving messages. If this field's value displays as false, check the server log for possible reasons for connection failure.
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
