On Apr 2, 2005, at 5:57 PM, Avi Bryant wrote:

> Sounds like you did a huge amount of benchmarking work.  I'm impressed
> :).  However, you seem to be conflating a lot of things in this
> message, which makes it hard to respond to.  There are at least three
> separate issues here, but you seem to be treating them as if they were
> linked:

Sorry if I created confusion. I'm just trying to gauge Squeak/Seaside 
and a DB against my past experiences with other development frameworks. 
I like what I've seen so far in Squeak but need to make sure of certain 
things before I invest too much time and effort to later realize it 
won't do what I need.

> - Ruby performance vs. Squeak performance

As a point of comparison only. Not really comparing the 
languages/features/frameworks, but simply it was rather quickly for me 
to test the same thing in RoR.

> - MySQL performance vs. GOODS and Magma performance

I definitely come from a MySQL world but I'm 100% new to OODB.

> - performance vs. responsiveness under load

Absolutely. This is extremely important for me.

> A few general notes in response:
>
> - You seem to be taking the poor performance of GOODS and Magma, both
> of which I would classify as experimental database systems (in the
> Squeak context anyway), as evidence that Squeak/Seaside isn't suitable
> for production work.

I'm not generalizing my decision based on this. I know from Magma's 
documentation, that Magma is in a more experimental mode than GOODS. I 
contacted a few of the companies that have developed applications with 
GOODS and they're all very happy. Unfortunately, none of the people I 
contacted have used it in the Smalltalk environment, so that may have 
something to do with it.

> The two don't go hand in hand; most production
> Seaside apps I've seen use PostgreSQL, MySQL, or OmniBase.

I trust that Seaside must perform excellent with these databases.

>   There are
> indeed a handful that use GOODS, but none of them with legacy data to
> import, and none of them with datasets of the scale you're describing.
>  I don't know of any using Magma.  So if you're seriously interested
> in evaluating Seaside's suitability for production, you might do well
> to evaluate it in a more common configuration.  In particular, since
> you seem more comfortable with relational databases, why not evaluate
> Squeak+Seaside+MySQL (or perhaps PostgreSQL, since that has better
> support from things like GLORP)?

I may just go that route. I was trying to keep everything as close to 
the object model as possible and stay away from RDBMS for once, but I 
guess I can't run away from them :). I read about GLORP and seems 
impressive, although I think it still needs work (I really like 
ActiveRecord from RoR). What about ROE?

> - There's absolutely no reason an extended database transaction should
> "block the VM" as you say, and no reason it should stop Seaside from
> serving pages (except, obviously, for the one session that's waiting
> for the database txn to complete).  I can't tell if you're actually
> seeing this or just assuming that would be the case.  If you are
> seeing it, I'd be very interested to know how and try to figure out
> why.

Let me expand on my definition of "block the VM". By this I mean that 
the Squeak UI is completely unresponsive. You cannot open a browse, a 
workspace, or anything. Not even the world menu. You can move the mouse 
but clicking anywhere does not do anything. You can, however, press 
Cmd+. to stop the process. The only way that I've tested Seaside's 
responsiveness while doing these tests was to: 1) launch WAKom, 2) 
point a browser to the store demo application, 3) do some navigation in 
the store demo to make sure it's working, 4) start the performance 
benchmarks, 5) try to do anything on the store demo. At step #5, the 
browser sends the request and nothing seems to happen until, either the 
browser times out or the benchmark ends and then Seaside responds. 
Immediately after the benchmarks end, you see Seaside's output in the 
Transcript window logging the request.

> - Did you have the WriteBarrier package loaded when testing the
> incremental update in GOODS?  I suspect you'll get pretty different
> results if you do.

No, I don't. Didn't know I needed it.

> - Please do try OmniBase on Windows if you can, to get a sense of what
> using a fast OODB from Squeak is like.  The issue with locking on
> Linux is not a long term one (we *do* use it in production on Linux
> internally), it's just a matter of getting the right version of the
> code out there.

I contacted David Gorisek about linux file locking and he informed me 
he doesn't have the file locking code for linux and he doesn't 
currently work with linux.

I believe you when you say that OmniBase will prove to be much 
different. I just don't trust Microsoft related products and oppose to 
test anything under Windows or even worse, run any production 
environment under Windows.

Avi, again thanks for your comments and help. I will give this whole 
thing a try with PostgreSQL or MySQL and see where that takes me.

Thanks again,
Daniel Salama