On 9 September 2011 07:33, Tomek kott <[email protected]> wrote: > Speaking of the new objectbroker functions, could someone more > knowledgeable than I correct my understanding of what each of the object > broker report headers is supposed to mean? Sorry if I missed this > somewhere... >
I added the columns in the object broker report but haven't documented them anywhere yet. Most of your definitions are correct so I'll just edit them below as needed. > *What counts as a "Hit"?* > The object in the objectbroker (i.e., a combination of the type, objectid, > webskin, url parameters, any other cachable information) was found and can > be returned as is. > > *What counts as a "Miss"?* > The object was not found at all in the objectbroker cache (could be > because it is the first hit, the type was flushed, etc.) > * > What counts as a "Flush"? > *The type object changed (i.e., someone edited a dmHTML) and or a > descendent changed > A flush is an explicit removal of an object via application.fapi.removeFromObjectBroker(). Flushes are usually due to an object being changed or deleted, or due to a "Rebuild Page" request. A "Rebuild Site" request causes the entire object broker and its contents to be discarded and replaced, so does not count as an object flush. > * > What counts as an "Eviction"? > *There is no more space in the objectbroker cache for this kind of object > OR > There is no more memory available for FarCry to use for the objectbroker. > Rather than crash, get rid of some entries > When the number of objects cached for a given content type exceeds the ObjectBrokerMaxObjects value for that type, the object broker removes 10% of the cached objects for that type. These removals are called evictions. Caches use an eviction policy to select the objects to evict. The current eviction policy for Farcry's object broker is FIFO (First-In First-Out), meaning the objects for that type that have been in the cache the longest are the first to be evicted. FIFO is the easiest eviction policy to implement but its not very efficacious as it can evict objects that are frequently/recently hit. Blair has investigated other eviction policies but no work has yet been started or scheduled for an alternate policy to be implemented for Facry's object broker. > *What counts as a "Null Hit"? > *The object should have been there, but the reference has been put in the > recycling bin awaiting to be reaped > A null hit occurs when the object broker finds a matching object reference in its cache, but the reference is now null because object that was previously there has been claimed by the Java Virtual Machine (JVM) for garbage collection. > > *What counts as a "Reap"?* > Objects that were put in the recycler and subsequently deleted from the > memory available. > A reap occurs when the object broker is notified by the JVM that a cached object has been claimed for garbage collection. When the JVM claims an object for garbage collection it first unlinks any soft references to it (ie. the object disappears from the application) but does not destroy the object immediately. Java provides reference queues to give applications a chance to perform any special processing after a tracked object is claimed but before it is destroyed. Farcry's object broker uses a Java reference queue to count reaps. > > > With all that said, I have a few questions: > > 1) If one had infinite memory, one wouldn't need to have any evictions, > right? > The occurance of evictions depends on the ObjectBrokerMaxObjects setting, not on available memory. If available memory is not a problem, you can prevent eveications by setting ObjectBrokerMaxObjects to a value greater than the total number of objects for that type. Setting ObjectBrokerMaxObjects high for all your types is not a good idea if you cannot fit all of your objects in memory. While the soft reference enhancement allows the JVM to recover from out-of-memory conditions, it's more work for the JVM to collect soft references than to collect dereferenced (ie. deleted) objects. If you increased ObjectBrokerMaxObjects for a type and start seeing a lot of null hits for that type, you should probably reduce the value. > 2) If there are null hits, one would also expect there to be a few reaps as > the recycler does its work, right? > Yes you would expect that, but I have yet to see it happen. Either there is a bug in the reference queue code, or the time between the JVM claiming an object and destroying it is too short for the object broker to catch and process the event. The JVM does not promise to wait for reference queues to process reap events before destroying queued objects. > 3) Generally a high hit/miss ratio is indicative that things are cached > well and that they aren't changing often. > That's exactly right. -- Dennis Clark | Developer | Daemon Internet Consultants | http://www.daemon.com.au -- You received this message cos you are subscribed to "farcry-dev" Google group. To post, email: [email protected] To unsubscribe, email: [email protected] For more options: http://groups.google.com/group/farcry-dev -------------------------------- Follow us on Twitter: http://twitter.com/farcry
