Java Reference
In-Depth Information
•
Pool resize quantity—
The number of beans to be removed when the pool idle
time-out expires. The default is 8.
•
Pool idle time-out—
The maximum number of seconds that a bean can reside in
the pool without servicing a request before it's released for garbage collection. The
default is 600.
These are only a few of the pool settings—there are many more. Each application is differ-
ent and it's important to tune pool settings to truly match your needs.
In modern JVMs, object construction is very cheap. Most modern JVMs also support gen-
erational garbage collection, which makes it efficient to destroy short-lived objects. Gener-
ational garbage collection is the default for the HotSpot VM. This means that it's typically
not necessary to specify a minimum size for a pool. It's all right for bean instances to be
created on the fly and destroyed after the idle time-out expires (unless a subsequent request
uses the bean again). This is why the default minimum pool size for most modern applic-
ation servers like GlassFish, WebLogic 12c, and JBoss 7 is set to zero. But you should
definitely specify a sensible minimum pool size if you're not using generational garbage
collection (for example, to reduce garbage collection overhead or minimize garbage collec-
tion pauses) or if your JVM doesn't support generational garbage collection. In such cases,
caching and reusing objects will significantly boost garbage collection performance. You
should also utilize minimum pool sizes for objects that are particularly heavyweight, slow
to construct, or use resources that aren't pooled like raw TCP-based connections.
It's almost always a good idea to specify a maximum pool size to safeguard against re-
source starvation caused by sudden bursts of concurrent requests. The typical default value
of maximum pool sizes is between 10 and 30. As a general rule of thumb, you should set
a maximum pool size matching the highest normally expected number of concurrent users
you have for a given service. Too low a number will make the application appear unre-
sponsive with long wait queues, whereas too high a number will risk resource starvation
under heavy load. (Similarly, you should specify a database pool size matching the total ex-
pected concurrent users for a system or the capacity of your database server.) Fast services
should have a lower maximum pool limit, and slower services should have a higher pool-
ing limit. If you truly have very high server capacity and must support a very large number
of concurrent users, it's possible to disable the upper limits of pools.
It's important to properly tune pooling for your individual application. Most application
servers will allow you to monitor the state of bean pools at runtime to help you with tuning.
