[Seaside] Re: Scaling Seaside apps (was: About SToR)

Jeremy Shute 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
every time).

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...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20060804/d797995f/attachment.htm

More information about the Seaside mailing list