My first Magma experience (Now including GOODS)
Daniel Salama
dsalama at user.net
Sun Apr 3 04:43:17 UTC 2005
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
More information about the Squeak-dev
mailing list
|