[Seaside] Re: GOODS
C. David Shaffer
cdshaffer at acm.org
Tue Nov 20 01:14:34 UTC 2007
Avi Bryant wrote:
> So you're finding that writes are the main bottleneck, and that read
> performance is fine? I'd be curious to hear more about this; in my
> own limited experiments the read performance was what concerned me
> most.
>
I have tuned the read code a bit (at the expense of support for
arbitrary GOODS class name -> Smalltalk class name mappings) and that
has improved the only problems I've had with reads. I think we're
getting close to being limited by network issues. I believe that GOODS
supports talking on a UNIX domain socket so it might be interesting to
see if that would improve things much. It hasn't been an issue for me
though. For applications where you rapidly populate large models you
might run into trouble...I don't have any examples of that. I worked on
an app last year, which never saw the light of day unfortunately, where
we had a fair number of large binary objects (png's and morphs) stored
in GOODS and reads were a bit sluggish. "a bit" here meant not bad
enough compared to non-GOODS related problems to be worth the time to
investigate. I've found tweaking the server.cluster_size parameter can
also help to alleviate read-related performance problems.
Performance problems with GOODS, in my experience, are typically:
1) connection time so I keep a pool of fresh connections around
2) writes when the cache is large or when you have large objects to
compare (arrays, for example) -- this requires some clever flushing
strategies to fix when it occurs
WriteBarrier seemed promising to fix #2 but it causes all kinds of other
problems for me. I had hoped to have funding to pay someone to
implement VM-level immutability support in Squeak...that would solve the
problem without bytecode tricks. But that funding fell through with the
aforementioned project. I think such a thing would substantially
benefit GOODS and Magma.
David
More information about the seaside
mailing list