Re: Managing EOF caching
Re: Managing EOF caching
- Subject: Re: Managing EOF caching
- From: Mike Schrag <email@hidden>
- Date: Sun, 22 Jan 2006 19:18:16 -0500
I think you're ascribing too much mysticism to it. Each snapshot has
the timestamp of when it was fetched. Those EO snapshots are hashed
and looked up by global id ONLY. When an EC requests an EO snapshot,
it requests with a global id and a fetch timestamp lag. The EO
snapshot is looked up with the global id by your EODatabase. If the
timestamp lag makes the EO "too old" for the request, EODatabase
returns a null instead of the EO, which to the call chain looks like
the EO was never fetched, which kicks off a fetch by global id
(basically just a primary key query). If you're seeing higher CPU
cost as a result of changing timestamp lag, it's not a DIRECT
function of the lag (meaning the time ALONE isn't increasing CPU).
Expiring timestamps MIGHT be kicking off an ugly series of fetches by
global id (i.e. a bunch of single object fetches). If you turn on
sql debugging you'd be able to see that pretty quickly, though. Just
a guess ...
Oh, and you are correct that you have a shared pool of snapshots (for
all EC's that have a common EODatabase). When an object is too old
for one EC, a new snapshot is fetched which will update EVERY ec that
is sharing that pool of snapshots.
ms
On Jan 22, 2006, at 6:01 PM, email@hidden wrote:
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:
40mdimension.com
This email sent to email@hidden
_______________________________________________
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