On 13-Apr-05, at AM 02:58, Daniel Salama wrote:

> GOODS: 201.553 seconds
> Omnibase: 3.102 seconds
> Magma: 73.578 seconds
> MySQL: 13.815 seconds
> RubyOnRails: 12.411535 seconds

snipped.

> I was a bit disappointed at the performance of GOODS. I like the GOODS 
> server and the people I have talked with regarding its performance 
> under "heavier" loads are very happy with it. Again, as I mentioned in 
> previous postings, they are not using Smalltalk. They are using Java 
> or C. As Avi said, it could be a performance tuning issue with the 
> Squeak GOODS classes and hopefully that would improve over time.
>
> Now, I hope my findings are useful to others. However, I would love to 
> hear feedback from others regarding this. I tried to make these as 
> equal and unbiased as possible. Also, the fact that I'm new to all 
> this may affect the quality and optimization of my code.

Looking at the GOODS test code, you are making 1000 changes and 
committing them serially with 1 connection. Assuming that you are 
trying to simulate a web application (since you included ROR and were 
talking about Seaside) with 1000 concurrent connections, this test 
might not reflect your true usage pattern (for GOODS, OmniBase and 
possibly Magma). I'm wondering if you use 1000 connections running on 
different threads, the numbers might be diffferent (better or worse).

--
HweeBoon
MotionObj
(65) 6764-9774