THE COST OF EJB OBJECT POOLING
EJB pools provide a good idea of the relative benefits of object pools, since a Java EE application
server can be tested with differently sized EJB pools to measure the difference in performance
between objects obtained from the pool and objects created on demand.
In this example, I used the GlassFish 4.0 application server with the standard stock history servlet.
The stateless bean in that application has virtually no initialization overhead. It does have a
@PostConstruct method, but that method is empty.
The @PostConstruct method is typically used for initializing resources; for example, it could
perform a (relatively expensive) Java Naming and Directory Interface (JNDI) lookup. To emulate
that, I changed the stock servlet's @PostConstruct method to sleep so it can mimic the time that
would otherwise be required to execute some initialization code.
Table 10-2 shows the response time from simulating 64 clients hitting that application with differ-
ent EJB pool sizes and sleep times in the @PostConstruct method.
Table 10-2. Effect of object pools on EJB response time
Size of EJB pool
Time to initialize
Average response time
With no initialization time, there is no benefit in having an EJB pool. But when initialization
takes 25 ms or 50 ms and the pool has a size of 1—meaning it must create a new EJB object for
each invocation—there is a predictable penalty in the average response time.
Since there are only 64 (small) objects in the EJB pool, the pool is unlikely to introduce any GC
penalty here. This is another key feature of a successful object pool: when it makes sense to use
one, keep it small.