• 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: Sat, 21 Jan 2006 17:51:30 +1300

Hello All;

Apple badly needs to get a Tech Bulletin on EOF memory and performance optimization.

Yes I have read around this and I agree that the holistic picture of EOF's workings for volume, resource-intensive processing is somewhat elusive -- some clear documentation in this area would be handy. I've had a bit of a battle with a batch process that took a substantial amount of time to complete. It would run *really* fast up to ~20% and then dramatically slowed down.


Following this discussion, I reduced the "fetch timestamp lag" on the processes' EC to ~1-2mins (from ~1hour) and now the process appears to run at a decent speed all the way through. I guess what's happening is that it's no longer undertaking the same volume of work when locating snapshots inside the running EOF stack -- something I assume would require many comparisons of hash codes against snapshots in memory. This might perhaps explain why it was slowing down in the way it did because I imagine at the start of the process there were less snapshots to be worked against compared to later in the process.

Is it that the "fetch timestamp lag" determines the potential snapshots that *could* be applicable for a fault occurrence and that actually all fetching events populate the snapshots for as long as there is memory (maybe using weak references?) or does this millisecond value determine the time-to-live of the snapshot inside the EODatabase instance where the snapshots are being stored?

What happens if you use two or more separate object store coordinators inside your application? Does this partition the set of snapshots in memory?

I remember that somebody (Art?) in this thread has discussed the idea of using a new EC for each iteration of some process and then letting the fresh EC slip into the garbage collector in order to free snapshots. Based on my understanding (which is mostly derived from my own thoughts on the matter rather than any authoritative fact) I'm not sure I comprehend exactly how this approach would control which snapshots were kept. Surely once one has saved changes within an EC, the actual snapshots involved are "relocated" to the associated EODatabase instance to be merged into other dependent ECs' "view of the world"? Assuming no undo stack and that any references to EOEnterpriseObject subclasses are broken, how does the interplay between an EC and maintenance of snapshots at the EODatabase level then work after a save changes has occured? I started to imagine how I would go about making this work if I were creating EOF, but I'd just be guessing. :-/

cheers.

___
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: Art Isbell <email@hidden>
  • Prev by Date: Re: Managing EOF caching
  • 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