On Apr 3, 2005 12:15 AM, Daniel Salama <dsalama at user.net> wrote:
 
> As I mentioned in a previous post, the more I work in the Squeak
> environment the more I want to develop my production applications
> there, but, what's going on? What am I doing wrong? I'll gladly post
> all the code for anyone to simulate it in their own local machine,
> include a dummy data file. Just ask for it and I'll send it.
> 
> Does anyone have any suggestion? At one time I thought it was my model
> design, but it really couldn't get any simpler than that. I just can't
> believe that it really takes this long to run, while blocking the VM at
> the same time.

Daniel,

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:

- Ruby performance vs. Squeak performance
- MySQL performance vs. GOODS and Magma performance
- performance vs. responsiveness under load

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.  The two don't go hand in hand; most production
Seaside apps I've seen use PostgreSQL, MySQL, or OmniBase.  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)?
- It's absolutely true that GOODS is unacceptably slow to do bulk
loads.  This is a known bug and I've mentioned it before.  In fact,
that it's only about 6 or 7 times slower than MySQL (an hour vs. 9
minutes) is surprising to me; I would have expected even more of a
difference.  It's also interesting that Magma seems to have similar
problems to GOODS in this area.
- 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.
- 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.
- 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.

Avi