Squeak SmalltalkJoker Squeak Smalltalk : Persistency : prevnext Concurrency Seaside GOODS Ruby On Rails

I'm working on duplicating a CRM application I developed using Ruby On 
Rails with MySQL. This application currently runs on a single server 
with dual 650Mhz CPUs and 2GB of RAM. Currently, my client has over 1 
million customer records and each record has at least one order in the 
system. They handle approximately 10000 application "transactions" per 
day (a transaction could be something as simple as looking up a 
customer profile, to something more complex such as placing and order, 
while interfacing with USPS using SOAP and the corresponding financial 
institutions using XML to verify payment information) with 
approximately 50 concurrent users.

My idea was to replicate that same environment with 
Squeak/Seaside/GOODS and, if everything worked well, eventually 
migrate to that environment.

----

The volume you mention (50 concurrent users, 10k txns/day) doesn't 
sound out of line.  I'd probably want a dedicated server for that, 
though.  And yes (as you asked earlier) it is possible to load balance 
Seaside apps across several servers or CPUs; I do it using some simple 
mod_rewrite rules, though the "pound" load balancer (google for it) 
would probably also work well.

Whether GOODS can reasonably handle the 1M customer records you 
mention, I frankly have no idea.  Actually, one of the problems with 
the GOODS client right now is that bulk loading is extremely slow, so 
I've never had the patience to get anywhere near that much data into 
it for testing.  For production apps these days I'm using OmniBase, 
which isn't ideal (for one thing, the Squeak port of the free version 
badly needs to be brought up to date, though the commercial version 
has been), but has been solid and scalable so far.

Avi

---
The scenario you presented talks about 1000 transactions a day. That's 
one every minute and a half. They're probably not evenly distributed, 
and there'll be peak load periods, but say that amounts to one every 
five seconds. You still hardly need any threading. I don't work with 
Squeak, or with Seaside, but in VisualWorks, with a very similar 
threading model, trivial page displays start to be a performance issue 
once you get a couple of hundred per second. I note that Cincom also 
has ObjectStudio, a Windows-native Smalltalk that uses Windows 
threads. Things that work very well in VisualWorks using lots of 
threads will crash Windows very quickly using native threads.

The primary thing to be careful of is things that block the entire VM. 
So if you have a call out to a database, or another external system 
you want to make sure that other processes can run while it's in 
progress. You also may have the issue that with two CPU's, a single 
Squeak image can only effectively use one of them. This is less of an 
issue if you have other stuff running on the same box.

I don't work with Squeak, or with Seaside, but in VisualWorks, with a 
very similar threading model, trivial page displays start to be a 
performance issue once you get a couple of hundred per second. I note 
that Cincom also has ObjectStudio, a Windows-native Smalltalk that 
uses Windows threads. Things that work very well in VisualWorks using 
lots of threads will crash Windows very quickly using native threads.

The primary thing to be careful of is things that block the entire VM. 
So if you have a call out to a database, or another external system 
you want to make sure that other processes can run while it's in 
progress. You also may have the issue that with two CPU's, a single 
Squeak image can only effectively use one of them. This is less of an 
issue if you have other stuff running on the same box.

---
If you're using sockets to communicate with these external systems, 
it's not blocking the VM.