Re: EO Caching (2)
Re: EO Caching (2)
- Subject: Re: EO Caching (2)
- From: Alexander Spohr <email@hidden>
- Date: Tue, 11 Dec 2007 18:11:19 +0100
Am 11.12.2007 um 16:11 schrieb Paul Hertz:
I think the major culprits in the code are 1) repeated calls to
ec.objectsWithFetchSpecification (a separate fetch for each
question, repeated rather than cached),
Could you fetch all questions belonging to one survey? Cache the
NSArray then.
and 2) faults fired one at a time on the fetched rows.
If you have a loop (or WORepetition) (batch)fetch the related objects
before the loop. All relationships will be complete and do not need to
be refetched.
Perhaps 3) statistical calculations performed on the answers to each
survey question slow things down significantly, too.
Hm.. what could I suggest? Don’t calculate, or calculate with another
app ;)
An additional problem is an EOAndQualifier that correctly filters
rows in a fetch but not in memory (filteredArrayWithQualifier).
Until I figure that out, I have to fetch answers for each question
separately--but at least I can eliminate repeated fetches for the
same question.
Could you do a GROUP BY HAVING? Not sure what kind of fetches you want
here.
Or maybe a simple batchFetch for the answers-relationship would do?
Faults only need be fired on multi-choice questions with multiple
answers, which are accessed through a flattend relationship.
Flattened relationships (apparently) do not get pulled in through
batch fetching--the relationship has to operate on a concrete field
of the entity one is fetching. So, batch fetching may not be a
solution (modifyng the databse may be).
Just batchFetch through the n:m-relationship to the target-table? You
just need to get the answers into memory, EOF does the rest (in the
same EditingContext)
Performing the fetches and statistical operations, etc., in a
threaded task in a WOLongResponse page, rather than having bindings
in the html/wod files trigger calculation, should provide a
reasonable solution to preventing timeouts, if not to speeding
things up. Even if the page still takes a long time to build and
load, the client will see some sort of progress indicator.
Is it possible to set up a second app for this? Or pre-calculate and
deliver html?
Finally, our WO server and our DB server are separate machines.
Possibly there are deeper-seated problems with the synchronization
of calls and database locking, but I'm going after the low-hanging
fruit first.
No, the database will be fast enough as long as you don’t fetch a
million records or poke it to death with single object fetches.
atze
Freeport & Soliversum
Alexander Spohr
email@hidden
www.freeport.de
_______________________________________________
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
| References: | |
| | >EO Caching (From: Jeffrey Simpson <email@hidden>) |