Why and when to perform this task
The size of your Enterprise JavaBeans (EJB) cache can effect the performance of the application server. One of the steps in tuning your EJB container to optimum performance levels is to fine tune the EJB cache. The following describes how to use the diagnostic trace service to help you determine the best cache size for you.Steps for this task
Set up your trace to use this trace string:
com.ibm.ejs.util.cache.BackgroundLruEvictionStrategy=all=enabled:com.ibm.ejs.util.cache.CacheElementEnumerator=all=enabled
Set Maximum File Size to 200MB or more. If you leave the default value of 20MB, you could fill up the single 20MB trace log and lose some data because of trace wrapping.
Set Maximum Number of Historical Files to 5. Five files should be sufficient, but if you see that all five files are full and trace wrapping occurs, increase this value.
BackgroundLru 3 EJB Cache: Sweep (1,40) - Cache limit not reached : 489/2053 BackgroundLru > EJB Cache: Sweep (16,40) - Cache limit exceeded : 3997/2053 Entry
Trace: 2007/03/22 11:47:07.048 01 t=7A9690 c=UNK key=P8 (13007002) ThreadId: 0000006a FunctionName: com.ibm.ejs.util.cache.BackgroundLruEvictionStrategy SourceId: com.ibm.ejs.util.cache.BackgroundLruEvictionStrategy Category: FINEST ExtendedMessage: EJB Cache: Sweep (23,40) - Cache limit not reached : 0/2053 Trace: 2007/03/22 11:54:16.755 01 t=7BD3B0 c=UNK key=P8 (13007002) ThreadId: 0000006d FunctionName: EJB Cache: Sweep (75,37) - Cache limit exceeded : 3801/2053 SourceId: com.ibm.ejs.util.cache.BackgroundLruEvictionStrategy Category: FINER ExtendedMessage: Entry
In the trace strings that include the words Cache limit you find a ratio. For example, 3997/2053. The first number is the number of enterprise beans currently in the EJB cache (called the capacity). The second number is the EJB cache setting (more about this in later steps). You will use this ratio, particularly the capacity, in your analysis.
Also look for the statements Cache limit not reached and Cache limit exceeded.
In the case where the cache limit is exceeded, you might see a trace point similar to this:
BackgroundLru < EJB Cache: Sweep (64,38) - Evicted = 50 : 3589/2053 Exit
EJB Cache: Sweep (64,38) - Evicted = 50 : 3589/2053Notice the Evicted = string. If you see this string, you are using either Stateful Session Beans or Entity Beans configured for Option A or B caching. Evicted objects mean you are not taking full advantage of the caching option that you have chosen. Your first step is to try increasing the EJB Cache size. If continued running of your application results in more evictions, it means that the application is accessing or creating more new beans between EJB Cache sweeps than the cache can hold, and NOT re-using existing beans. At this point, you might want to consider using Option C caching for your entity beans, or checking your application to see if it is not removing Stateful Session Beans after they are no longer needed.
Note: Entity beans configured with Option C caching are only in the cache while in a transaction, and are required to be held in the cache for the entire transaction. Therefore, they are never evicted during a cache sweep, but are removed from the cache when the transaction completes.
Your ultimate goal is to set the cache limit to a value that does not waste resources, but also does not get exceeded. So, a good set-up gives you a trace with only the Cache limit not reached message, and a ratio where the capacity number can be near, but below, 100% of the EJB Cache setting.
Note: It is recommended that you do not set your cache size to anything less than the default of 2053.
What to do next
From your analysis, it is possible to set the EJB cache optimally from an EJB Container perspective, but perhaps not optimally from a WebSphere Application Server perspective. A larger cache size provides more hits and better EJB cache performance, but uses more memory. Memory used by the cache is not available to other areas of the product, potentially causing the overall performance to suffer. In a system with ample memory, this might not be an issue and properly tuning the EJB cache might increase overall performance. However, you should take into account this system performance versus EJB cache performance when configuring the cache.