Re: EOSharedEditingContext
Re: EOSharedEditingContext
- Subject: Re: EOSharedEditingContext
- From: Anjo Krank <email@hidden>
- Date: Fri, 21 Dec 2007 08:05:20 +0100
Am 21.12.2007 um 07:39 schrieb Jonathan Miller:
But given the scenario where you have a lot of objects that are
going to be read only e.g. the front end of a web site, what is the
best strategy?
1. Create a session per visitor and use the session's default
editing context.
2. Constructing a new editing context for everyone component that
fetches objects.
3. Some other method?
Depends?
- how fresh do you need your data?
- is the DB a bottleneck? are fetches expensive?
- how much mem you want to use/need (overall/per visitor)
- is it cheaper to re-fetch than use the cached items?
- do you have long-running sessions?
- do you have lots of shared data between users? each user has its own
set?
- do you have to care or can you simply set up another machine?
As an example, what we have is several thousands of content items that
switch their online/offline state on a very regular basis. The items
are grouped into 100s of categories which are in a menu (omitting
those categories that don't have items).
We also noticed a few things, like that unvisited categories are
extremely expensive when someone finally goes there. Since they are
most likely expired from the snapshot cache, you have to fetch and
group ~10k items when the user visits the page and this can take >10
secs - which in turn seriously annoys the users...
So what we do at the moment is have an extra thread constantly reading
and grouping in a different EOF stack and pushing the fetched snapshot
dict into the "main" EODatabase. The "normal" ECs have a fetch
timestamp lag of 24 hours, so that they always use the cache unless
you fetch with setRefreshed(true). I might consider putting that stuff
in memcached at some time or another but have to check if this is any
faster (I doubt it). Adn as our pages render in 0.08 secs on average
it's not a problem anyway.
This is (apart from illustrating how fiendishly clever we are) just an
example of what you may have to do when you actually *know* what a
problem is...
Cheers, Anjo
_______________________________________________
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