Java Reference
In-Depth Information
Just how do you know what values to use for the size of the EJB pools and caches? One way is to
make an educated guess based on knowledge of how the application works in conjunction with its
expected load. But the only way actually to know if too many EJBs are being created (or too
many stateful session beans are being passivated) is to use the monitoring facilities of the applica-
tion server.
Figure 10-1 shows an example of how the monitoring is accomplished in GlassFish. In this case,
the number of EJBs destroyed is not zero, indicating that some EJBs were created and then des-
troyed because there was no available bean in the pool for that operation. Accordingly, the num-
ber of EJBs created is greater than the maximum pool size (which in this case was four). That is
an indication that the EJB pool is undersized.
Figure 10-1. Sample EJB pool monitoring
It is important to monitor statistics like this in order to understand the performance of applica-
tions, but be aware the monitoring itself imposes some cost. In this case, I set the GlassFish mon-
itoring level for the EJB container to HIGH to generate those statistics, and the total throughput
dropped by about 5%. That's a small price to pay for some visibility into an application, but for
application servers that offer configurable monitoring, pay attention to what you need and config-
ure monitoring accordingly. In the case of GlassFish, configuring the monitoring level to LOW has
a negligible impact—that monitoring can be used for most operations, and monitoring can be dy-
namically set to HIGH when more information is required.
Search WWH ::

Custom Search