• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Managing EOF caching
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Managing EOF caching


  • Subject: Re: Managing EOF caching
  • From: email@hidden
  • Date: Mon, 23 Jan 2006 12:01:00 +1300

Hello Ken;

I do understand the end-user result of using the "lag" setting. What I do not entirely understand is the manifestation of the underlying architecture in terms of snapshot storage and performance of looking up in those in-memory snapshots.

I have seen that a ~1 hour lag setting causes significant CPU costs during a fault once there's a large number of snapshots in memory owing to a very large number of EO's having been faulted over a long period of time. I no longer see this CPU cost when the lag is very short despite having faulted a very large number of EO's. This behaviour is good for the system I'm engineering. Surely in both cases (long lag and short lag) EOF would have to sift through all the snapshots in order to find the one it wants in the same fashion? Why then do I see such a marked performance difference? I'm not interested in the "data-freshness" aspects to this nor the database- communication costs, but more the performance implications inside the in-JVM EOF stack.

Each EC can have it's own "lag" so I assume that the pool of snapshots under consideration when a fault is being undertaken is the same across all the EC-s which share a common EOObjectStoreCoordinator instance. In other words, EC-s share the same pool of snapshots regardless of the lag used for a fault.

I would be interested in *how* it's selecting the snapshots based on the "lag" -- ie: the internal mechanics of it. Are the snapshots partitioned in memory by timestamp somehow as to be very efficient for this "lag influenced" lookup or is the "lag" somehow effecting the volume of snapshots that are sticking around in memory in addition to the reference-counting that has been described here in the past few days?

cheers.


As I said in my previous email, snapshots have an NSTimestamp for when they were retrieved. If, when the EC gets a snapshot for an EO that is being created in that EC, the snapshot NSTimestamp is older than the lag, the snapshot will be refetched.

___ Andrew Lindesay www.lindesay.co.nz



_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Managing EOF caching
      • From: Mike Schrag <email@hidden>
References: 
 >Re: Managing EOF caching (From: email@hidden)
 >Re: Managing EOF caching (From: Ken Anderson <email@hidden>)

  • Prev by Date: Re: Couting the objects that would be returned by a fetch specification
  • Next by Date: Re: Managing EOF caching
  • Previous by thread: Re: Managing EOF caching
  • Next by thread: Re: Managing EOF caching
  • Index(es):
    • Date
    • Thread