by
dcooper@jade.co.nz >> Fri, 28 Jul 2006 1:12:35 GMT
The "maximum cache size" means that the cache did in fact grow to this size (which is roughly 4MB, which is also the cache limit). This is a normal thing to see. For example, if you're running your system for a while and it executes 4MB or so of different methods, then your method cache will have naturally grown to the 4MB cache limit. The key thing in terms of performance is the "no cache overruns" - this is good. When JADE executes a method, the Interpreter needs to bring that method into its method cache (if it isn't already there). If it needs to bring the method into cache, it will grow the cache (assuming it's not already at its limit) or swap out enough old and not-in-use methods to make room. The key thing in terms of "overruns" is the not-in-use bit. If a method is active in the current call stack, the Interpreter cannot swap it out of cache. So if you have a call stack (for example) that requires more than 4MB of methods, the Interpreter will temporarily grow the method cache to accomodate that call stack (even if this is more than the cache limit) and then reduce it back down to the cache limit when the call stack unwinds. This will show up in the profiler as a cache overrun and the profiler output will give you details of the methods that caused the overrun. In the case of a cache overrun, the profiler will report a maximum cache size of more than the cache limit, in which case the maximum cache size is saying "if your cache limit was set to this, you wouldn't have had any overruns".
In terms of multiple application servers, every *node* in a JADE system (ie: application servers, the database server and standard [aka "fat" or two-tier] clients) has a method cache that is controlled by the settings in whatever ini file the node is looking at. So the above behaviour applies to each node in a JADE system.
Dean.