Filter
Top Products
to the steady load of users), beans would be frequently passivated and activated, causing a
negative impact on the response times, due to CPU intensive serialization and deserialization as
well as disk I/O.
Another important variable for tuning is cache-idle-timeout-in-seconds where at periodic
intervals of cache-idle-timeout-in-seconds, all the beans in the cache that have not been
accessed for more than cache-idle-timeout-in-seconds time, are passivated. Similar to an
HTTP session time-out, the bean is removed after it has not been accessed for
removal-timeout-in-seconds. Passivated beans are stored on disk in serialized form. A large
number of passivated beans could not only mean many les on the disk system, but also slower
response time as the session state has to be de-serialized before the invocation.
Checkpoint only when needed
In high availability mode, when using stateful session beans, consider checkpointing only those
methods that alter the state of the bean signicantly. This reduces the number of times the bean
state has to be checkpointed into the persistent store.
Stateless Session Beans
Stateless session beans are more readily pooled than entity or the stateful session beans. Valid
values for steady-pool-size, pool-resize-quantity and max-pool-size are the best
tunables for these type of beans. Set the steady-pool-size to greater than zero if you want to
pre-populate the pool. This way, when the container comes up, it creates a pool with
steady-pool-size number of beans. By pre-populating the pool it is possible to avoid the
object creation time during method invocations.
Setting the steady-pool size to a very large value can cause unwanted memory growth and
can result in large garbage collection times. pool-resize-quantity determines the rate of
growth as well as the rate of decay of the pool. Setting it to a small value is better as the decay
behaves like an exponential decay. Setting a small max-pool-size can cause excessive object
destruction (and as a result excessive object creation) as instances are destroyed from the pool if
the current pool size exceeds max-pool-size.
Read-Only Entity Beans
Read-only entity beans cache data from the database. Application Server supports read-only
beans that use both bean-managed persistence (BMP) and container-managed persistence
(CMP). Of the two types, CMP read-only beans provide signicantly better performance. In the
EJB lifecycle, the EJB container calls the ejbLoad() method of a read-only bean once. The
container makes multiple copies of the EJB component from that data, and since the beans do
not update the database, the container never calls the ejbStore() method. This greatly reduces
database trac for these beans.
If there is a bean that never updates the database, use a read-only bean in its place to improve
performance. A read-only bean is appropriate if either:
EJB PerformanceTuning
Chapter2 • TuningYourApplication 43