At 09:33 16.06.00 -0700, Peter William Lount wrote:

>As for the size of Squeak images it's mostly a matter of your specific
>configuration requirements - if you are just running one or a few copies of
>squeak then size won't matter but if your running 100+ copies then @ 10MB
>per image you'll have 1000MB+ in your swap file and have a need for lots of
>RAM$$$.

Actually, for "real" servers, that's not too much.  Our comany application 
server for example (a Sun E250 I think) has 2GB. If you want to work with 
Sun's StarPortal or other application servers, Sun itself calculates with 
30 MB per user (they want to improve that in future), recommending very 
large (and expensive) server with up to 64 GB (E10000, $1000000 and 
above).  But of cause, Sun makes money selling these kind of computers :-)

But I agree that small is beautiful.  Just to test, while writing this 
lines, I'm running 10 headless Squeak stripped to 1.5 MB image size and 
restricted to only 4 MB of RAM.  My system becomes a little bit sluggish 
(30% workload just because of Squeak sitting around) but a PII 400 (with 
256 MB) seems still be fast enough.  So with a current cpu, it should work 
quite well.  I've however no idea what would happen, if the Squeaks would 
do something.  Currently, they're just wasting memory...


>  I'd like to see the squeak web object application server images be
>about 1 or 2 megabytes if possible. This would allow running 50 to 100
>copies on my existing server (with just a little RAM upgrade). Assuming
>Squeak can handle 5-10 requests at the same time

Probably not with a default Squeak.  I haven't tested but I think I read 
something like that socket requests are serialized because the VM can't 
deal with multiple simultaneous request.  Or perhaps that's only true for a 
Mac?

File i/o is definitely serialized, so when one server process reads a file, 
the whole VM is stopped.  The AsyncFile class might help here, but I'm not 
sure whether that's really supported by the image and all platforms.  So 
I'd assume that one squeak can only deal with 1-3 requests at once if at all.

>With the above working we can put together professional and highly
>scaleable web sites that rival any created with PERL etc. The cool part is
>that squeak can then fit into an existing web site technicial strategy and
>CO-EXIST with other solutions that use PERL, PHP, C, Java, JavaScript,
>plugins, etc.... This is very important.. I'd like to see 1 million web
>sites using Open Source Squeak Smalltalk!!

Yes.

>I have thought alot about creating an apache module that would use SOAP or
>some other XML tag protocol to talk with application servers. Any such
>apache module for squeak would have to support most of the feature points
>of FastCGI and JServ. FastCGI essentially does what we need - it just
>doesn't use XML for the protocol content communication. The advantage of
>using the fastcgi protocol is that it exists and works in all the major web
>servers enabling Squeak to be used with Microsoft, Netcape, Apache and
>other web servers.

SOAP and XML also have a large overhead - if compared to the size of data 
transfered both in size and in parsing (mashalling/unmarshalling) time.

bye
--
Stefan Matthias Aust  //  Bevor wir fallen, fallen wir lieber auf