[Seaside] Re: GOODS

[C. David Shaffer]

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