Cache Sizing

[torrie]

I was wondering if someone can confirm exactly what the cache sizes are specifically around the ObjectCacheSizeLimit settings. Am I correct in assuming that"

1) The PersistentDatabase.ObjectCacheSizeLimit setting in the INI sets the memory used to cache the physical database in memory on the database server node. This is there to reduce the number of disk reads.
2) The JadeServer.ObjectCacheSizeLimit is used to cache the working set of objects being used by server applications or server execution methods.
3) The JadeClient.ObjectCacheSizeLimit is used to cache the working set of objects being used by the client nodes (app server's, or fat clients.)

I would assume that if a user requests an object, either the caches in 2 or 3 above are checked, then if the object is not found, the cache in 1 above is checked. If the object is still not found, then it is read from disk.

With that understanding, if the users are doing the majority of the work in a system (thin client) and there is only one application server, would the recommendation be to have a larger server cache (ie increase the setting in 1 above) or to have a large cache in the application server (3 above.)

If the cache specified in 1 above is larger than 3, I would assume that the any requests for an object from the application server would require the object to be send through TCP or shared memory to the application server, potentially resulting in more network / shared memory traffic. However if the cache in 3 is larger than the cache in 1, then the application server would have a larger cache hit rate, while any server applications or server execution methods would have a lower cache hit rate as the server and persistent database caches (2,3) would contain less objects.

Thanks

Torrie

[Matthew]

Sorry for the lengthy reply, but there is a lot of considerations and I've only just scratched the surface.

The common cache's section in the Performance Analysis Whitepaper provides a bit of an overview of the cache's in question here. (available at http://www.jade.co.nz/downloads/jade/pa ... alysis.pdf).

Assumption one is correct except for that the next step is file system cache not a physical disk read in most instances.

I would assume that if a user requests an object, either the caches in 2 or 3 above are checked, then if the object is not found, the cache in 1 above is checked.

- If the object is still not found then a read to the operating system is issued, if the result is not in file system cache then a read to the physical disk occurs.

The balance of allocating your physical memory to the various caches will be very dependent on the application itself, but in general terms you want to cache your objects as close to where the logic is executing as possible. Don't overlook the fact that in a 32-Bit Environment you are most likely best off leaving significant amounts of memory available for file system cache. In a 32-Bit environment you have to be very aware that the logical address space limit is likely to restrict how large a cache you can specify.

With that understanding, if the users are doing the majority of the work in a system (thin client) and there is only one application server, would the recommendation be to have a larger server cache (ie increase the setting in 1 above) or to have a large cache in the application server (3 above.)

In general terms you would be more likely to increase the JadeClient.ObjectCacheSizeLimit in this scenario as this would result in the objects being cached closer to where they would be executing.

The aforementioned white paper provides a number of examples which may be of further help.


Matthew

[torrie]

Thanks for the reply. I have read the white paper following the post which also answered my questions. We've manged to get more physical memory allocated to the machine and increased the cache sizes which has reduced the % read time on the database drive.

Thanks for the indication that it's better to allocate to the cache closest to the executing logic. I'll bear that in mind if we need to make more changes.