[Seaside] Re: Scaling Seaside apps (was: About SToR)
shutej at crazilocks.com
Fri Aug 4 19:46:40 UTC 2006
As I said, I don't think the cursors are going to help the whole 10-12x
issue. What I am doing is essentially very write-heavy.
I read the table for some context. "Dear database, what was the state of
the object last time I retrieved it from the network?" The cursor would
help here, as right now I'm seeking each object one-at-a-time. A cursor
would eliminate needing to construct this query in the middle of the loop,
and store where I am in the B-tree (instead of skipping down from the root
But, looking at the process browser, the messages in the GLORP-operating
thread seem to relate to the assembly of queries. The cursor would
eliminate the READ queries, but the WRITE queries are still necessary,
requiring assembly one-at-a-time, unless GLORP is smart enough to use a
global prepared statement underneath for insertions. I see no reason why it
shouldn't be -- insertions are very homogenous operations, unlike WHERE
clauses. Perhaps a cursor WOULD solve the problem?
Really, I need to profile the message sends to see exactly where the CPU
time is going, but one thing is for sure, the CPU is pegged.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Seaside